When an AI agent uses your username, your session token, or your OAuth grant to get something done, the record it leaves behind says you did it. Not the agent. You. Every log line, every audit trail, every “who approved this refund” investigation points at a human who may have been asleep at the time.
Separating agent identity from human identity fixes exactly one thing, and it is the thing everything else depends on: it makes the record true. An agent with its own identifier leaves a trail that says this agent, acting for this person, took this action, with these permissions, at this moment. Without that, every control downstream — least privilege, revocation, anomaly detection, compliance evidence — is built on a lie about who acted.
An agent that inherits a human’s credentials doesn’t just get that human’s access. It gets their alibi.
The three kinds of identity, and why agents are a third kind
Most enterprise identity systems recognise two categories. Human identities are people: they log in, they get challenged for a second factor, their access is reviewed once or twice a year. Non-human identities — service accounts, API keys, certificates, machine tokens — are software: they’re provisioned once, given broad permissions so nothing breaks, and then largely forgotten.
Agents fit neither shape. They act on a person’s behalf like a human, but at machine speed and without a human watching each step. They chain across systems, calling tools that call other tools. And they’re ephemeral in a way service accounts never were — spun up per task, sometimes per session.
| Human identity | Service account | Agent identity | |
|---|---|---|---|
| Authenticates with | Password, passkey, MFA | Long-lived key or secret | Short-lived, cryptographically bound credential |
| Permissions change | At a quarterly access review | Rarely, if ever | Per task, per session |
| Acts on behalf of | Itself | A system | A named person, and itself |
| Typical lifespan | Years | Years | Minutes to hours |
| Who’s accountable | The person | Ambiguous | A named human owner |
That last row is the one organisations get wrong. An agent with no assigned owner is an actor nobody is responsible for.
What breaks when an agent borrows a human identity
Four failures follow from credential inheritance, and they compound.
- Attribution collapses. If the agent presents your token, the system it calls has no way to tell an agent’s action from yours. Desktop agents that drive a browser on your behalf are the sharpest version of this — from the application’s side, it is simply your session doing things.
- Privilege becomes permanent. An HR agent authorised to offboard employees should hold that power for the seconds it takes to run the offboarding, not for every second it happens to be running. Developers who can’t predict exactly which permissions an agent will need tend to grant the union of everything it might need, and nobody trims it later.
- Delegation loses its intent. “This agent may act for Tyler” is a different claim from “Tyler asked this agent to do this specific thing.” Only the second is auditable.
- Nothing checks at the point of use. The agent’s authority is typically evaluated when it starts, not when it reaches the database. By the time it touches sensitive data — possibly several hops downstream — no system is asking whether that access is still appropriate for this request, in this context, at this moment.
The OWASP Non-Human Identities Top 10 names most of these directly: improper offboarding of identities that outlive their purpose, overprivileged non-human identities, identity reuse across services, and humans using service accounts as shortcuts. Published before agents were the dominant case, it reads now as a forecast.
Worth knowing: Estimates of how many non-human identities an organisation holds per human range from roughly 45:1 to well over 100:1, depending on who counted and what they counted. The spread is the finding. Nobody has an accurate inventory, which is the real problem the ratio is pointing at.
How separation works mechanically
The pattern that has emerged across every serious implementation has four parts.
Each agent instance gets a unique identifier at registration. Not a shared one per agent type — per instance, so a specific running agent can be traced.
Credentials are short-lived and bound to the thing holding them. Rather than a static key that works anywhere it’s copied, the agent holds a certificate or token tied cryptographically to its runtime, so a stolen copy is useless elsewhere.
Delegated tokens carry both identities. When an agent acts for a person, the token says so: it names the user and the agent, so audit logs can show both. This matters because “the agent acted” and “the agent acted because Priya asked it to” need different responses when something goes wrong.
Each hop re-scopes and re-audiences the token. Instead of one broad credential flowing end to end, each step exchanges its token for a narrower one addressed specifically to the next service. A service receiving a token that doesn’t name it as the intended audience rejects it — which is what stops an attacker from injecting a fabricated identity into the middle of a workflow. The underlying mechanism, OAuth 2.0 Token Exchange, has been a published standard since 2020; routing it through an API gateway means individual developers never have to implement it.
What has actually shipped
Every major cloud has an answer, and the answers differ enough to matter if you run agents in more than one.
| Platform | Agent identity model | Notable mechanics |
|---|---|---|
| Google Cloud Agent Identity | A SPIFFE identifier per agent, used directly as an IAM principal | Auto-provisioned X.509 certificate valid 24 hours; access tokens cryptographically bound to it; audit logs show both agent and user when acting on someone’s behalf |
| Microsoft Entra Agent ID | Generally available; a three-tier model of blueprint, blueprint principal, and per-instance agent identity | Conditional Access and Identity Protection for on-behalf-of agents evaluate against the user’s token, so the human’s licensing governs the agent’s controls |
| Amazon Bedrock AgentCore Identity | Agent identities implemented as workload identities, collected in a per-account agent identity directory | A token vault holds refresh tokens; the documented design goal is agents authenticating as themselves rather than impersonating users |
| Okta | Agent SSO registers agents in Universal Directory alongside employees; the separate Okta for AI Agents product adds discovery and governance | Agent SSO went generally available on 24 August 2026 and is included in core Okta SSO at no extra cost — which decides whether a control gets deployed or merely piloted |
Google’s documentation carries a warning the others should copy: deleting an agent does not remove the permission grants that referenced it. They stay in your policies as inactive bindings, and redeploying the same agent produces a new identifier that those old grants don’t cover. Decommissioning is a manual step, and skipping it is precisely the improper-offboarding failure that tops the OWASP list.
The standards are further behind than the products
The Model Context Protocol, revision 2026-07-28, treats a protected MCP server as an OAuth 2.1 resource server and requires clients to bind every token to a specific server using resource indicators — good, necessary hygiene that closes off a class of token-confusion attacks. But the specification describes clients and servers. It has no concept of an agent as an actor with its own identity.
The nearest thing is the Enterprise-Managed Authorization extension, which MCP marks as stable. It profiles the Identity Assertion JWT Authorization Grant — the mechanism informally called Cross-App Access — so a company’s identity provider can decide which clients may reach which servers on which users’ behalf. Read the grant’s own specification carefully, though, and the limit is explicit: the token binds a user to a client application. Its authors note that this preserves the client binding without identifying or authenticating any actor in an on-behalf-of chain.
So the current standards landscape breaks down like this:
- Settled: token exchange, audience restriction, protected resource metadata, short-lived credentials. All published RFCs.
- Close: identity chaining across trust domains, approved by the IETF and awaiting publication; the identity assertion grant, an active working-group draft.
- Open: a portable, vendor-neutral way to say which agent took an action. NIST’s National Cybersecurity Center of Excellence published a concept paper on software and AI agent identity and authorization in February 2026 and closed its comment window; the project is still being scoped.
Cloud-native agent identity is real and deployable. Cross-vendor agent identity is not, and anyone selling it as settled is selling.
Why this reaches you personally
In April 2026, Vercel disclosed that an attacker reached its internal systems through an employee’s Google Workspace account. The entry point was not a stolen password. An employee had signed up for a third-party AI tool using their corporate account and granted it broad permissions; that tool was compromised, and the attacker replayed the resulting OAuth token. From every system’s perspective, it was a valid, authorised access relationship behaving normally.
That is the whole problem in one incident. The grant was real. The consent screen was legitimate. And the tool’s identity and the employee’s identity were, for practical purposes, the same identity.
Two things follow for anyone who isn’t running an enterprise identity programme:
- Audit your third-party app grants. In Google and Microsoft account settings, review which applications hold access and what scope they were given. Any AI tool holding a broad grant can reach everything you can reach, and it will keep reaching it long after you stop using the tool.
- Treat “Allow All” as a decision, not a formality. The permission you skim past is the permission an attacker inherits.
What separation doesn’t buy you
Giving an agent its own identity answers who acted and makes revocation possible — cut one agent’s credentials without locking a human out of their job. Those are the two things you need at three in the morning, and they’re worth the deployment effort on their own.
It does not answer whether the human meant it. An agent with a perfectly attested identity, a correctly scoped token, and a flawless audit trail will still do the wrong thing if its instructions were poisoned somewhere upstream. Identity tells you which actor to blame and which credential to kill. Intent — proving that the person actually asked for the action the agent performed — remains genuinely unsolved, and the specifications circling it are drafts with no implementations behind them.
Build the identity layer anyway. It’s the prerequisite for everything that comes next, and unlike the intent problem, it has answers you can deploy this quarter.