I have told you five times on this site to treat every AI agent like a service account: log it, scope it, audit it. I never once showed you the mechanism, and that was a cop-out, because the advice is half wrong. A service account is a static, long-lived shared secret. An agent is the opposite. It wakes up, acts on behalf of a different human or a different upstream agent each run, crosses trust boundaries, and dies. Hand it a service account and you have minted exactly the thing breach reports keep flagging: a non-human credential nobody rotates and nobody can attribute.
The reason I never wrote the mechanism down is that there isn't a single credential to issue. The working answer in mid-2026 is two layers, and the teams getting burned are the ones collapsing them into one.
Why "treat it like a service account" backfires
Layer one is workload identity: cryptographic proof of what the agent process actually is. Layer two is delegated authority: a short-lived, scoped token that says what this agent may do this minute and on whose behalf. SPIFFE answers "who is this code." OAuth answers "what is it allowed to do right now, and for which user." They are not interchangeable, and the failure I keep seeing is a team picking one and assuming it covers the other.
A static API key issued to an agent gives you neither. It does not prove the running process is the agent you think it is (anyone who reads the env var is now that agent), and it carries no notion of which user the agent is acting for on a given call. You have a string. Strings leak.
The scale problem is already here
The Cloud Security Alliance's State of Non-Human Identity survey puts the ratio of non-human identities to human ones at more than 90 to 1 in many organizations, and as high as 144 to 1 in some. Agents now sit inside that non-human bucket. Every one of those is an authentication event your SIEM has to attribute to something.
The naive play, one OAuth client secret or one API key per agent, multiplies the static-secret sprawl that credential-theft and supply-chain incidents feed on. You are not solving the identity problem at that ratio. You are turning it into a key-management problem at a scale no human rotation schedule survives.
What SPIFFE actually gives you
SPIFFE issues identity without a secret to steal. The core construct is the SVID, a short-lived, cryptographically signed credential that a SPIRE server issues only after runtime attestation of the workload. The identity is bound to what the process is (its image, its node, its selectors), not to a string someone pasted into a deployment manifest. HashiCorp's own write-up on securing agentic and non-human actors makes the point plainly: there is no long-lived API key to rotate, store, or leak.
In practice the part that bites teams is attestation policy. An SVID is only as trustworthy as the selectors SPIRE checks before issuing it. If you attest on something weak, you have rebuilt the shared-secret problem with extra steps. Get attestation right and you have something a static key never offered: an identity you can revoke by simply letting it expire, because it was short-lived from the start.
Impersonation vs. delegation decides your audit trail
This is the one-line decision most teams skip, and it is the part you discover after an incident instead of before.
OAuth 2.0 Token Exchange (RFC 8693, a published standard since 2020, not a draft) draws a hard line between two patterns. Impersonation means the agent takes on the user's identity and becomes, in the spec's own words, indistinguishable from that user. Delegation means the acting party stays distinguishable from the party it acts for. RFC 8693 defines a Security Token Service that trades one token for another and supports both. The agent presents its own credential plus the user's token and gets back a new token scoped to one task.
If you let the agent impersonate the user, your access logs say the user did it. When the agent goes wrong, and prompt injection guarantees a fraction of them will, your incident responders cannot tell whether the human or the machine pulled the data. Least privilege collapses at the same time, because you can only scope down a principal you can still see. Choosing delegation over impersonation is the single decision that keeps your audit trail intact, and it costs you one parameter in the token request. Teams pick impersonation because it is easier to wire up, then pay for it during the postmortem.
The standards are still fighting, so commit carefully
This is a live standards fight, not a settled pattern, and that changes what you are allowed to hard-code.
NIST launched its AI Agent Standards Initiative in February 2026, and its concept paper openly asks whether OAuth, OpenID Connect, and SPIFFE are sufficient for agents or whether new standards are needed. Microsoft shipped Entra Agent ID and treats agents as a first-class identity, distinct from both users and service principals. The IETF has at least two competing drafts in flight. One, "OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents," adds a requested_actor parameter to name the specific agent needing delegated access and an actor_token parameter to authenticate that agent during the code-for-token exchange. A competing AAuth draft proposes a dedicated Agent Authorization Grant instead.
The vendors disagree on naming more than shape. CSA frames the gap as a non-human-identity governance vacuum. Strata argues agents are not non-human identities at all. What they agree on, every one of them, is that workload proof and delegated authority are two different things. So bet on the stable layers (RFC 8693 and SPIFFE), and keep the agent-specific draft parameters behind an adapter you can swap. The standard underneath is safe to commit to. The extension on top is not, and if you wait for it to settle before doing anything, you will be provisioning agents with API keys for another eighteen months.
The multi-hop chain is where attribution dies quietly
Single-agent delegation is the easy case. The damage scales when agents call agents.
MCP adopted OAuth 2.1 with PKCE in 2026, and A2A supports RFC 8693 token exchange for the case where agent A calls agent B on behalf of a user. This is exactly where impersonation shortcuts quietly destroy attribution, not across one hop but across three. If each hop impersonates, a three-agent chain laundered one user's identity through three services and your logs show a single human doing all of it. If each hop does a proper token exchange, the same chain produces three attributable, scoped tokens. The delegation chain, not the individual call, is the unit your audit has to reason about. The reference shape showing up in financial-services deployments in mid-2026 reflects this: SPIRE as the enterprise workload identity authority for the "what is this agent" layer, OAuth delegation layered on top for the "acting for whom" layer, deliberately not merged into one credential.
Where to start before the next agent ships
Work this in order. Each step ties to a specific above.
- Inventory every agent authenticating with a long-lived API key or static OAuth client secret, and replace those first. This is the credential class with a breach-report number behind it. Stand up SPIRE as your trust domain and issue SVIDs with runtime attestation so there is no static secret left to leak. Audit your attestation selectors while you are there; a weak selector rebuilds the problem.
- Check whether your agents impersonate or delegate today. Pull your access logs for any agent-driven action. If the actor field shows the human when the agent did the work, you are impersonating and you have no attribution. Move to RFC 8693 delegation so the agent stays distinguishable in every token and every log line.
- If you run more than two agents that call each other (A2A or MCP chains included), require token exchange at every hop. Treat the chain as the audit unit. A three-hop chain should produce three scoped tokens, not one impersonated user identity passed along.
- Do not hard-code either IETF agent draft. Build on RFC 8693 and SPIFFE, and put
requested_actorandactor_tokenbehind an adapter you can swap when NIST's initiative or the AAuth draft lands.
- Set the cutover trigger at a non-human-to-human identity ratio of 50 to 1. Past that point, manual key rotation is already losing to volume, and short-lived SVIDs stop being a nice-to-have. Given that CSA is seeing 90 to 1 and 144 to 1 in the field, most organizations crossed this line a while ago and have not noticed.
Sources
- https://datatracker.ietf.org/doc/html/rfc8693
- https://www.ietf.org/archive/id/draft-oauth-ai-agents-on-behalf-of-user-01.html
- https://techcommunity.microsoft.com/blog/microsoft-entra-blog/microsoft%E2%80%99s-perspective-on-agentic-identity-standards/2111910
- https://www.hashicorp.com/en/blog/spiffe-securing-the-identity-of-agentic-ai-and-non-human-actors
- https://spiffe.io/docs/latest/spire-about/spire-concepts/
Comments
Be the first to comment.