What is agent identity?
Agent identity is how an agent proves what it is and whose authority it is using, at the moment it calls something. It answers a runtime question, which is different from the record of what agents exist and different again from proving afterwards who an action was for.
Those three questions get conflated, so it is worth separating them once. The agent registry answers what exists and who owns it. The AI audit trail answers, afterwards, on whose authority something was done. Agent identity is the mechanism that makes the second answer true at the time, by binding the agent and the person together in the call itself.
Three things get treated as one, and separating them prevents most of the confusion. The Cloud Security Alliance draws the distinction cleanly: there is the agent, the identity it uses, and the credential it presents. An agent is not itself an identity, and one agent may legitimately use several depending on what it is doing and for whom. A conversation about "the agent's permissions" is usually a conversation about one credential and misses the other two.
Why do existing identity systems not work for agents?
Because they were built for two kinds of principal. A human authenticates and acts for themselves. A service acts for itself with a fixed, knowable scope. An agent authenticates as itself while acting for a different person each time, and can acquire access after it is issued.
That last property is the one that breaks the model. Identity governance assumes you can determine a principal's reach when you provision it, and for an agent you cannot.
| Principal | Acts for | Reach at issue | Why the difference matters |
|---|---|---|---|
| Human | Themselves | Known, and reviewed periodically | Authentication ceremonies assume a person present to perform them |
| Service | Itself, for one fixed purpose | Static and determinable when created | You can reason about the blast radius on day one |
| Agent | A different person on each invocation | Not determinable. It can acquire more | Neither category's tooling constrains it, so it inherits whichever it was filed under |
The practical consequence is that agents get filed as service accounts, because that is the nearest existing box, and a service account is precisely the wrong model. A service account is a static principal whose reach you can determine when you create it. An agent is a dynamic actor whose reach you cannot. Treating the second as the first means your permission review, your rotation schedule, and your blast-radius assessment are all computed against a fiction.
Four deployment patterns are in common use, and they carry different identity requirements.
| Pattern | How it works | Where it fits | Main risk |
|---|---|---|---|
| User-delegated | The agent acts on a user's authority with explicit consent | The dominant pattern for productivity and assistant use cases | Consent granted once and reused far beyond its original scope |
| Autonomous | The agent holds its own standing identity and acts for itself | Scheduled and background work with no human trigger | No principal to attribute to, so accountability defaults to the owner |
| Orchestrated | One agent delegates to others in a chain | Multi-agent pipelines and sub-agent architectures | Authority propagating undiminished down the chain |
| Scoped | The agent acts as the user, restricted to narrow scopes | High-risk actions where impersonation must be tightly bounded | Scopes drifting wider over time without review |
What is the confused deputy problem?
A less privileged party gets a more privileged party to act for it. An agent holding broad permissions, executing a request from a user who holds narrow ones, performs actions that user could never have performed. The permission check passed. It checked the wrong principal.
The problem is decades old and agents make it easy to trigger, because they are trusted, connected, and responsive to whatever text reaches them. This is the central identity failure in agentic systems.
Two things make it worse in an agentic setting than in classical software. The request need not come from a person at all. A document the agent reads can supply it, which is the link to prompt injection. And nothing in the authentication layer catches it, because the agent really is who it claims to be. Its token is valid; its scopes are correct. Authentication was never the failing control.
Worth being precise about what standard protocols do and do not cover here. OAuth 2.1 terminates at the resource server boundary: it confirms the token is valid and the agent holds the right scopes. It does not prevent a correctly authenticated agent being manipulated into misusing that authority. The protocol is doing its job. The job it does is not this one.
How should an agent act on a user's behalf?
Carry two identities on every call and bind them together for that task alone. The agent authenticates as itself, the user's authority travels separately, and the action is authorised against both. Three facts, composed once per invocation rather than assumed.
This is the pattern the field has converged on during 2026, and it is worth implementing as described rather than approximated, because each part carries weight.
-
Give the agent its own standing identity
The agent is authenticated as itself, not as a shared service account and not by borrowing a user's credential wholesale. This is what makes the agent a nameable actor in the record and lets you revoke one agent without affecting others.
-
Establish the user separately
Authenticate the human through your normal identity provider so you know who they are, then carry that authority as its own fact on the call rather than folding it into the agent's credential. The two identities stay distinguishable all the way to the resource server.
-
Bind them into a delegated execution context
A bounded binding of one specific user to one specific agent for one specific task. Scoped to the task rather than the session, so consent granted for one purpose cannot be reused for another three weeks later. Token exchange, as standardised in RFC 8693, is the established mechanism.
-
Authorise against the intersection
Compute the effective permission as what the user may do and the agent may do, never the union. Enforce it at a policy layer in front of the tools rather than inside the agent, because a control the agent evaluates is a control an injected instruction can argue with.
-
Issue short-lived, narrowly scoped tokens
Per invocation rather than per session, expiring in minutes rather than months. Since the reach of an agent credential cannot be determined when issued, limiting how long it lives is the compensating control.
-
Attenuate at every hop
When one agent delegates to another, the downstream agent should receive strictly less authority than the upstream one, never the same and never more. Undiminished propagation down a chain is how a narrow request ends up executing with broad rights several agents away.
One regulatory pointer worth noting: Singapore's cyber security agency addendum on securing agentic AI treats identity spoofing and impersonation as a named threat, and prohibits cross-agent privilege delegation unless explicitly authorised. That is the attenuation rule stated as a requirement rather than a recommendation, and it is a reasonable bar to hold yourself to regardless of jurisdiction.
How do agents prove identity to each other?
Imperfectly, and this is the least settled part of the subject. In the Agent-to-Agent protocol, agents use something called Agent Cards to publish who they are and who's operating them. The problem is that nothing verifies any of it. The agent simply declares this information about itself, and it's taken at face value.
The protocol work is genuine progress and its limits are as significant as its contributions, which matters if you are planning to accept work from agents outside your organization.
- Agent Cards are self-asserted. The document states capabilities and operator, and no third party attests to model provenance, training lineage, or behavioural conformance. A malicious or simply misconfigured operator can publish whatever card it likes.
- Signing proves origin, not trustworthiness. A signed card establishes that the agent is who it claims. It establishes nothing about whether that agent should be given your data, which is a policy decision you still have to make about each counterparty.
- The tool surface is separately covered. The Model Context Protocol added OAuth 2.1 for its HTTP transport in January 2026, mandating proof key for code exchange and prohibiting the weaker grant types. That secures agents talking to tools; the agent-to-agent surface is the other half. See agent interoperability.
- Nobody has solved delegated authority across organizations. Establishing that an external agent is authentic is tractable. Establishing whose authority it is exercising, and whether that person consented to your systems being touched, is not yet standardised.
The practical stance for now is to treat an external agent as an untrusted counterparty that happens to be authenticated. Give it its own narrowly scoped identity in your systems, do not extend it authority derived from your own users, and log the exchange as a cross-boundary event rather than as an internal call. Standards work is moving, including a NIST initiative launched in February 2026 covering agent security and governance controls, so expect this section to date faster than the rest of the page.
What breaks at agent lifecycle speed?
Every process built around human employment timescales. Identity governance assumes onboarding, periodic review, and offboarding measured in months, whereas agents get created and abandoned inside a week. The result is entirely predictable: the credential outlives the agent almost every single time.
This is the unglamorous half of agent identity and it produces most of the standing exposure, because nothing about it is urgent until it is.
- Provisioning without a record. An agent gets a credential during a prototype and never gets an entry anywhere. It is now a principal in your estate that no inventory knows about, which is the same failure described at agent sprawl viewed from the identity side.
- Rotation on a human schedule. Annual or quarterly rotation is meaningless for a credential that should have lived for minutes. Short-lived tokens make rotation an implementation detail rather than a calendar event.
- Deprovisioning that never happens. The most common finding in any credential audit. The experiment ended, the team moved on, and the credential is still valid. Nobody deletes something they cannot see, which is why identity and inventory are one problem.
- Permission accretion. Agents gain access to solve specific problems and rarely lose it afterwards. Over a year an agent scoped to one system holds credentials for six, and the blast-radius assessment from day one no longer describes anything.
Two controls do most of the work here. First, never issue a long-lived agent credential. That way expiry is the default, and continued access requires continued justification. Second, tie credential issuance to a registry entry, so an agent can't get an identity unless an owner is recorded against it. That second control turns a security problem into a process problem, which is a considerably better problem to have.