AI agent identity management is the practice of giving every AI agent its own governed identity. That identity carries a named owner, credentials scoped to one task, a delegation record that says which person it acts for, and a log of what it did. Most estates we look at have none of that, because the agent signs in as the employee who set it up. That is how the Vercel incident of April 2026 began. Vercel’s bulletin says the compromise started at Context.ai, a third-party AI tool one employee used. The attacker used that access to take over the employee’s Google Workspace account, then the employee’s Vercel account. From there they pivoted into a Vercel environment and decrypted non-sensitive environment variables for a subset of customers. No exploit and no malware on Vercel’s side. An AI tool held a person’s authority, and the person’s authority was enough.
We wrote the leadership half of this argument in our CISO case for AI agent governance. This is the engineering half: what an agent identity consists of, which standards shipped in 2026, and which controls survive a hijacked agent.
Why IAM for AI agents fails on borrowed identity
The pattern repeats across the incidents of the past eighteen months. In the Salesloft Drift campaign of August 2025, a chat agent’s OAuth tokens gave one actor access to Salesforce instances at more than 700 organizations. The abuse ran from August 8 until Salesloft and Salesforce revoked every active access and refresh token on August 20. In May 2025, Invariant Labs showed that a malicious issue in a public GitHub repository could steer a coding agent into leaking private repository data through the GitHub MCP server. The agent did it with the user’s own token, because that token reached every repository the user could. Invariant’s point was that the MCP server code was not at fault. The agent simply had more reach than its task needed.
OWASP made this a named risk when it published the Top 10 for Agentic Applications on December 9, 2025. ASI03, Identity and Privilege Abuse, opens with the diagnosis we would give ourselves: without a distinct, governed identity of its own, an agent operates in an attribution gap that makes true least privilege impossible to enforce. Identity there means both the agent’s persona and every credential that stands for it, API keys, OAuth tokens and delegated user sessions included.
The scale is what makes this urgent rather than academic. Netskope Threat Labs estimates that each agent a user launches holds around ten OAuth grants, so 1,000 employees running five agents each means roughly 50,000 live tokens. Most were issued months ago and never reviewed, on platforms where the default is that a token lives until someone revokes it. MFA fired once, at consent. Everything after that is silent, which is the scene below in one frame.
AI agent identity management in three layers
When we design this for a client, we separate three things that a single service account used to blur together. The first is the agent’s own identity, the thing that answers which workload is calling. The second is the authority it exercises, which is usually a person’s. The third is the evidence of what it did with that authority. Confuse the first two and you get the Vercel pattern; skip the third and you cannot tell.
The first layer is workload identity, and it is not new. SPIFFE issues attested cryptographic identities to workloads, and the IETF’s WIMSE working group is standardizing that model. Identity providers have now built agent-specific constructs on top. Microsoft Entra Agent ID creates each agent’s identity from a blueprint, with parent-child relationships, and brings in agents built elsewhere through an auth sidecar or workload identity federation. Its protocol page is refreshingly strict: agents are confidential clients only, interactive sign-in flows are unsupported, managed identities are the preferred credential, and client secrets should not be used in production. Since May 2026 every new Copilot Studio agent gets an Agent ID automatically, with no opt-out. That is the right default, and we want it from every agent platform.
The NIST NCCoE concept paper of February 2026 frames the same layer as its first area of interest, identifying agents so that access management can distinguish agent from human and manage the range of actions from human-approved to autonomous. It names OAuth 2.0 and 2.1, OpenID Connect, SPIFFE and SPIRE, and SCIM among the candidate building blocks, which tells you the standards exist. The discipline is what is missing.
OAuth for AI agents acting on behalf of users
The second layer is where most engineering effort goes, because an agent that books travel, files tickets or merges code is spending a person’s authority. The wrong answer, reusing the person’s session token, is exactly the Drift and Vercel failure. The right answer already existed in RFC 8693, OAuth 2.0 Token Exchange, whose act claim lets a token carry the user as subject and the agent as actor, so a downstream API can see both and log both.
In 2026 the working group built the cross-domain version. The Identity Assertion JWT Authorization Grant, draft 04 of May 21, 2026, lets an agent take the identity assertion it received at single sign-on and obtain an access token for a SaaS tool through the enterprise identity provider that the tool already trusts. The draft calls the pattern Cross-App Access, its appendix uses an AI agent calling an external tool as the worked example, and the example grant expires in five minutes. On June 18, 2026 the MCP project declared its Enterprise-Managed Authorization extension stable on top of that grant, with no per-server consent screen, Okta as the first identity provider, and Anthropic’s Claude clients and VS Code among the early adopters. Okta’s June 23 announcement listed more than 25 early adopters, including Atlassian, Slack, Figma, Supabase and Cursor. It is still a draft, and yet it is the first delegation mechanism for agents with real deployments behind it, which is why we now put it in architecture reviews.
The academic side reached the same design earlier. South and colleagues argued in January 2025 for authenticated delegation that extends OAuth 2.0 and OpenID Connect with agent-specific credentials, and the OpenID Foundation’s October 2025 whitepaper turned that into a strategic agenda for agent-centric identities and delegated authority. Read those two before any vendor deck, because they are what the vendor decks paraphrase.
What breaks when an agent inherits permissions
ASI03’s example list reads like our incident reviews, so it is worth walking. A manager agent hands a worker agent its full access context because scoping was inconvenient. An IT agent caches SSH credentials during a patch and a non-admin later prompts it to reuse them. A sorting agent forwards a crafted email to a finance agent, which trusts internal agents and pays. A procurement agent validates a spending limit at the start of a workflow, the limit is cut hours later, and the old token completes the purchase anyway. An attacker registers a fake helper agent in an internal registry and inherits trust from its descriptor.
Every one of these is a delegation chain with a missing link, and none of them needs a prompt injection to start, although injection makes them worse. The confused deputy, an agent following planted instructions with its own valid token, is the case we covered in our prompt injection guide, and identity design decides how much damage the deputy can do. The third layer, evidence, decides whether you find out. The Drift tokens were abused for twelve days before revocation, and the GitHub MCP leak landed in a public pull request. Neither authentication log looked unusual, because the credentials were legitimate. Detection for agents has to live at the action layer: which agent, acting for whom, called which tool against which resource, with a token issued when. If your logs cannot answer that sentence, you have the Vercel gap.
Mitigation: controls that hold when an agent is hijacked
Here is our order of operations, in prose because nothing here needs a query. First, one identity per agent, never a shared service account and never a person’s session; OWASP’s mitigations for ASI03 start in the same place, with per-agent identities and short-lived credentials such as mTLS certificates or scoped tokens. Second, delegation through token exchange or ID-JAG, so the agent’s identity and the user’s authority stay separate claims. Third, no static secrets, which means workload identity federation or managed identities for the agent runtime, sender-constrained tokens through DPoP or mTLS where the platform supports them, and task grants that expire in minutes. Fourth, task-scoped grants and tool allowlists, with a human approval step for anything irreversible; Invariant’s fix for the GitHub case was simply limiting the agent to the repositories the task needed.
Fifth, a registry with an owner and an expiry for every agent, run through the lifecycle we described for non-human identities, plus an inventory of the OAuth grants those agents hold. Sixth, action-layer telemetry with a tested revocation path, because the honest measure of this program is how many minutes it takes to cut an agent off.
Products exist for pieces of this. Names that come up are Entra Agent ID and Okta’s Cross App Access on the identity side, and agent discovery and observability tools on the evidence side. Evaluate them against the three layers rather than the other way round, and hold any design to the joint CISA and ASD guidance on careful adoption of agentic AI services published on May 1, 2026. This is the work we do in our LLM and agent security engagements, and the delegation layer is usually where the design review finds the hole.
Frequently asked questions
What is an agent ID?
In Microsoft’s usage, an Agent ID is a Microsoft Entra identity created for one AI agent from an agent identity blueprint, so the agent authenticates as itself, inherits Conditional Access and governance, and appears in sign-in and audit logs. Generically, an agent ID is any distinct, attributable identity for an agent, as opposed to a borrowed human account or a shared service account.
Is there an AI agent identity standard?
Not a finished one. The pieces are existing RFCs (OAuth 2.0 Token Exchange, JWT authorization grants, DPoP) plus drafts. ID-JAG covers cross-app delegation, an IETF individual draft of March 2026 applies the WIMSE architecture to agents rather than defining new protocols, and the NCCoE project is scoping a demonstration of how those standards fit together. MCP’s Enterprise-Managed Authorization is the first agent-specific profile with production deployments.
Can SPIFFE give AI agents an identity?
Yes for the runtime, no for delegation. SPIFFE and SPIRE attest a workload and issue it a cryptographic identity, which covers the first layer for self-hosted agents. Acting on behalf of a user still needs an OAuth delegation flow that carries the user’s authority alongside the agent’s identity.
How do you authenticate an AI agent on behalf of a user?
Exchange the user’s assertion for a token that names both parties. RFC 8693 token exchange does that inside one domain with the act claim, and ID-JAG does it across domains through the identity provider, which is what Okta’s Cross App Access and MCP’s enterprise authorization implement. Reusing the user’s own session token is the pattern to remove.
Bottom line
Give every agent its own identity and carry the user’s authority through token exchange or ID-JAG rather than a borrowed session. Kill static secrets, scope each grant to a task with minutes of life, and log at the action layer so you can revoke in minutes. Vercel’s April 2026 incident started with one tool holding one employee’s authority. The fix is architectural, and it is available now.