Four vendors shipped agent identity in six months, and the comparison that matters is not which one gives an agent a nicer directory entry — it is what the agent is still holding five minutes after you revoke it. On that axis the four products are not close, the differences cost money in two cases, and in two cases the vendors have not said.
At a glance
Dates and prices below are the vendors' own announcements; the "not documented" entries are the honest answer to a question none of them has published.
| Product | Shipped | What the agent gets | What revocation stops |
|---|---|---|---|
| Okta Agent SSO | GA 24 Aug 2026 | A Universal Directory identity plus a short-lived token per connection | The next token exchange |
| Microsoft Entra Agent ID | GA Apr 2026 (per Entra release notes) | A directory object per agent, available to all Entra customers | The object — enforcement needs Agent 365 |
| Gemini Enterprise agent | Announced 8 Oct 2026, private preview | A Workspace account with its own address and audit trail | The account; subagents not documented |
| 1Password for Agents | Announced Oct 2026 | No identity — a brokered fill the agent never reads | The next request |
Two different shapes, sold under one word
Three of these four are issuers. They create a principal for the agent and hand it something to carry. The fourth is a broker: it creates nothing and carries the secret itself, releasing it into a sign-in form the agent can use but not read. Both shapes are defensible. They answer different questions, and a procurement conversation that treats "agent identity" as one category will buy one and believe it got the other.
The issuer question is who is calling. The broker question is what can leak. An agent compromised by prompt injection is not impersonating anybody — it is the legitimate principal, doing the wrong thing with its own credentials — so the issuer answer buys you attribution and a revocation path, not prevention. The broker answer buys you the opposite: nothing to exfiltrate, but no record of which agent did what.
Okta Agent SSO — the one whose revocation is fast because the grant is short
Okta brought the open Cross-App Access standard into its core SSO product with Agent SSO's general availability on 24 August 2026, at no additional cost on core SSO plans. When an agent connects to an enterprise application it is registered in Universal Directory alongside human employees, and Okta issues short-lived, identity-governed tokens in place of stored credentials. Cross-App Access removes the runtime user-consent screen; the connection is managed by Okta administrators instead.
Why this is the architecturally interesting one
The mechanism is an ID-JAG — an Identity Assertion JWT Authorization Grant — composing RFC 8693 token exchange with the RFC 7523 JWT bearer grant. The client holds its IdP login, asks for an ID-JAG naming one specific server as audience, and exchanges that for an access token at the server. The grant itself is not a bearer credential and says so: the exchange response carries token_type of N_A.
Because the ID-JAG is minted per audience and per expiry, policy is evaluated at every mint — group membership, conditional access, device posture — and a revocation in the IdP means the next exchange simply fails. This is also the protocol's answer, not just Okta's: Cross-App Access underpins Enterprise-Managed Authorization, which the MCP 2026-07-28 specification names as a formal extension alongside Tasks and MCP Apps. We took the mechanics apart in Enterprise-Managed Authorization.
The caveat is the same one EMA carries: it authorises the connection, not the tool call. Nothing here decides whether transfer_funds may run with those arguments at that hour.
Entra Agent ID — the identity is free, the leash is the paid part
Microsoft's Entra release notes list the Agent ID platform as generally available since April 2026, and creating agent identities is available to all Entra customers, though some admin-centre wizards remain labelled preview. Every agent becomes a first-class directory object, which is the right primitive and the one most likely to survive a decade of enterprise IAM.
Read the licensing as part of the security model
Microsoft's documentation puts the agent-facing security controls — Conditional Access and ID Protection extended to agents — behind Microsoft Agent 365, which went generally available on 1 May 2026 in Microsoft 365 E7 or standalone at USD 15 per user per month. So the directory entry costs nothing and the enforcement that makes the entry mean something is a separate purchase. Sources also differ on the required base subscription, which is a reason to check your own agreement rather than a blog's summary.
That split is not a pricing complaint; it is an architecture fact to plan around. A deployment that creates Entra agent identities without the add-on has an inventory, an audit trail and a name per agent — genuinely useful, and the basis for an agent registry — but the thing it does not have is a policy evaluated at each connection. Note also that the licence is quoted per user, not per agent, which is the right shape for a world where one person runs eleven agents.
Gemini Enterprise — a mailbox is an identity people can actually see
At Gemini at Work on 8 October 2026 Google described persistent "coworker" agents that get their own Workspace account, with audit logs attributed to the agent rather than to a human user, and temporary subagents each carrying their own identity for longer jobs. Reporting puts the address format at @agents.company.com, which Google has not confirmed in its own materials. It is in private preview with no published price.
The genuinely new idea, and the genuinely missing answer
Giving the agent a mailbox is not a gimmick. It makes the agent addressable by humans in the systems they already use, puts it in the org chart, and gives every artefact it produces an author that is not a confused human account. That is a real answer to the attribution problem that principal-agent confusion creates in shared channels.
What is unstated is the part that matters for this comparison. Whether a subagent's identity is revoked when its job ends, and whether a subagent's permissions can exceed its parent's, have not been published — and those two questions are the entire blast radius of a delegating agent. Our page on what a subagent inherits exists because the answer is almost never "nothing".
1Password for Agents — the only one that answers "what can leak"
Announced in October 2026, 1Password for Agents lets an agent sign in without ever receiving the credential. The agent proves itself to 1Password with a unique digital key, the user approves or denies that specific request, and 1Password fills the secret directly into the sign-in form rather than handing it to the agent. The company describes a Credential Broker that releases secrets only when needed, without exposing them to the agent or the underlying model. It is free for Individual and Family accounts on 1Password.com.
Architecturally this is the strongest answer in the set to the question that actually produces incidents — an agent cannot exfiltrate a password it never held, and a model cannot memorise one it never saw. And it is the one product here not positioned at enterprises. 1Password and Okta have both said they are backing shared identity standards so an agent's verified identity and authorisation context can travel between their systems; until that lands, you are choosing between attribution and non-exposure rather than getting both.
Three products tell you which agent called. One makes sure it never had the secret. Nobody yet sells you both in one invoice.
When to pick which
| Situation | Pick | Because |
|---|---|---|
| Agents reaching enterprise SaaS, and you need revocation to be fast | Okta Agent SSO | Per-connection ID-JAG means policy is re-evaluated at every mint |
| Microsoft-centred estate, inventory and audit are the first problem | Entra Agent ID | A directory object per agent for free; budget Agent 365 for enforcement |
| Agents that must appear in human workflows and own their output | Gemini Enterprise | A real mailbox and per-agent audit trail; pin down subagent revocation first |
| Personal agents touching sites with no enterprise SSO at all | 1Password for Agents | The agent never holds a secret, which is the failure you cannot patch later |
Whichever you buy, the question to put to the vendor in writing is the one the matrix above leaves half-empty: after I revoke, what is the longest-lived artefact this agent still holds, and how do I shorten it? Everything else in an agent-identity pitch is downstream of that number. And none of these products makes a per-tool authorisation decision, so policy-as-code at the tool boundary is still yours to build.
FAQ
Does giving an agent its own identity stop prompt injection?
No. A compromised agent is the legitimate principal acting wrongly with its own credentials, so identity buys attribution and a revocation path rather than prevention. The controls that limit damage are per-tool policy, scoped credentials and short token lifetimes.
What is an ID-JAG?
An Identity Assertion JWT Authorization Grant: a short-lived assertion an enterprise IdP mints for one named audience, composed from RFC 8693 token exchange and the RFC 7523 JWT bearer grant. It is not a bearer credential — the exchange response reports a token_type of N_A — and it is traded for an access token at the target server.
Is Entra Agent ID enough on its own?
For inventory, naming and audit, yes. For enforcement, Microsoft's documentation routes agent Conditional Access and ID Protection through Microsoft Agent 365, which is a separate licence at USD 15 per user per month or part of Microsoft 365 E7.
Can I combine a credential broker with an enterprise identity issuer?
Not as a shipped product today. 1Password and Okta have each said they are backing shared standards so verified agent identity and authorisation context can carry across systems, but until that exists you are picking which half of the problem to solve first.
Which of these does MCP actually use?
The Cross-App Access flow behind Okta Agent SSO is what MCP's Enterprise-Managed Authorization extension is built on, and that extension is named in the 2026-07-28 specification alongside Tasks and MCP Apps. The other three are platform identity products rather than MCP mechanisms.
Further reading
On this wiki:
- Enterprise-Managed Authorization — the ID-JAG flow and why token lifetime is the whole benefit.
- MCP Auth: the OAuth 2.1 Profile — what EMA replaces.
- Agent Directory Accounts — running agents as principals in your IdP.
- Credential Lifetime — why the TTL is the control.
- Access Reviews for Agent Credentials — the recurring work this creates.
- Agent Identity & Attestation — signed Agent Cards, runtime attestation and verifiable credentials.