AI Agent Identity: Why Shared Service Accounts Break Authorisation, and What Replaces Them
Give every agent its own identity, and when it acts for a person, put both in the credential: the user it acts for and the agent doing the acting. OAuth 2.0 Token Exchange (RFC 8693) defines exactly that delegation. Then make each credential short-lived, scoped to the task and bound to one audience, so a leaked or misused token is worth little and every action traces back to an agent and a person.
On this page
Suppose three agents run on one service account. One triages support tickets, one reconciles invoices, and one drafts weekly reports. The billing system's log shows a refund issued by svc-ai-platform at 02:14.
Which agent issued it? Was a person behind the request? Was that agent supposed to be able to issue refunds at all? The log cannot say, because as far as the billing system knows, there is only one actor.
Why shared service accounts break AI agent authorisation
A shared service account fails in four ways at once.
Least privilege becomes impossible. The account needs the union of every agent's permissions, so each agent effectively holds all of them. The report-drafting agent can issue refunds because the reconciliation agent needs to.
The weakest agent sets the risk. An instruction injected into the agent that reads untrusted email inherits every right on the account.
Attribution disappears. OWASP's Top 10 for Agentic Applications states it precisely under ASI03 Identity and Privilege Abuse: without a distinct, governed identity of its own, an agent "operates in an attribution gap that makes enforcing true least privilege impossible".
Revocation is all or nothing. You cannot cut off one misbehaving agent without cutting off the rest.
Our guide to tool-call authorisation for AI agents makes per-agent identity its first rule. This post is about what that identity has to carry, and for how long.
What NIST's NCCoE is asking about AI agent identity
In February 2026, NIST's National Cybersecurity Center of Excellence published a draft concept paper, Accelerating the Adoption of Software and AI Agent Identity and Authorization, with public comment open until 2 April 2026. It proposes a project to apply existing identity standards to agents, and it asks for input rather than giving guidance. The questions are the useful part:
- Should agent identity metadata be ephemeral, tied to a task, or fixed?
- How should key management for agents work: issuance, update and revocation?
- How do you establish least privilege for an agent whose required actions may not be fully predictable?
- How do you handle delegation of authority for "on behalf of" scenarios?
- How do you bind agent identity to human identity for human-in-the-loop authorisations?
Its areas of interest include access delegation: linking specific user identities to agents "to support effective delegation controls and maintain accountability". The standards it names include OAuth 2.0 and 2.1 with their extensions, OpenID Connect, SPIFFE/SPIRE, SCIM, NGAC and MCP.
Delegation vs impersonation: how an AI agent should act on behalf of a user
When an agent acts for a person, there are two ways to build the credential, and RFC 8693, OAuth 2.0 Token Exchange, names both.
Impersonation: the agent is given the user's rights and is "indistinguishable from" the user in that context. Every system it touches sees the user. This is, in effect, what happens when an agent is simply handed the user's session token.
Delegation: the agent "still has its own identity separate from" the user. In the RFC's terms, where A acts for B, "any actions taken are being taken by A representing B". As it puts it, "A is an agent for B".
In a JWT, delegation is expressed with the act (actor) claim. The token's subject is the user; the actor is the agent:
{
"iss": "https://auth.example.com",
"sub": "maria@example.com",
"aud": "https://billing.example.com",
"act": { "sub": "agent:invoice-reconciler" }
}
The exchange request can also name the target system (resource or audience) and the scope, so the token the agent receives is for one system and one job. When one agent hands work to another, act claims nest: the outermost is the current actor, and nested ones record prior actors. The RFC is explicit that access decisions use the token's top-level claims and the current actor only; prior actors are informational.
Delegation is the right default for agents because it keeps both facts the log needs: who asked, and who acted. Impersonation keeps only one, and records the user as having done what the agent did.
Chains of agents need a second rule. OWASP's ASI03 describes a low-privilege agent relaying valid-looking instructions to a high-privilege one, which executes them "without re-checking the original user's intent". That is the confused deputy problem, one agent removed. Each hop should be authorised against what the original user delegated, not against what the previous agent asked for.
Short-lived, scoped, audience-bound credentials for AI agents
An identity is only as good as the credential that carries it. A long-lived API key in an environment variable is an identity anyone who finds it can borrow.
Short-lived. The MCP Authorization specification says authorisation servers "SHOULD issue short-lived access tokens to reduce the impact of leaked tokens". For the workload itself, SPIFFE issues short-lived cryptographic identity documents that are regularly reissued.
Scoped to the task. OWASP's first ASI03 mitigation is to issue "short-lived, narrowly scoped tokens per task". Short lifetimes also limit a failure OWASP lists as time-of-check to time-of-use: permissions validated at the start of a workflow that have changed or expired by the time the agent acts.
Bound to one audience. The IETF's OAuth 2.0 Security Best Current Practice (RFC 9700) says access tokens should be audience-restricted to a specific resource server, and that a server must refuse a token not meant for it. MCP makes this mandatory: servers must validate that tokens were issued for them, and "MUST NOT pass through" the token they received to upstream APIs.
Bound to the sender. RFC 9700 also recommends sender-constrained tokens, through mutual TLS (RFC 8705) or DPoP (RFC 9449), to prevent misuse of stolen and leaked tokens.
| Shared service account | Per-agent delegated identity | |
|---|---|---|
| Who acted | "The platform" | A named agent |
| For whom | Unknown | The user in sub |
| Permissions | The union of every agent's | The task's scope, within the user's rights |
| A leaked credential | Works until someone rotates it | Expires soon, and is refused by other systems |
| Revocation | Stops every agent | Stops one agent, or one delegation |
An AI agent identity checklist
- Does every agent have its own identity, distinct from every other agent and from any person?
- When an agent acts for a user, does the credential name both, or does the agent impersonate the user?
- Are tokens short-lived and scoped to the task, or does the agent hold a standing key?
- Is each token restricted to the one system it is meant for, and refused everywhere else?
- When one agent delegates to another, is the second hop checked against what the original user authorised?
- Can you revoke a single agent without stopping the others?
- Does every action record which agent acted, for whom, under which credential? That is the "on whose authority" field of an AI agent audit trail.
Where Syntrox fits
Identity applies to the checker too. Syntrox sits outside the agent and records, for each trace it evaluates, the score, confidence and judge version, so the record of what was checked does not rest on the agent's account of itself. Every Nucleus verdict is stamped with the judge model and version that produced it, and because Nucleus runs at temperature 0 with a fixed seed, the same input gives the same verdict.