Your Agent Is Impersonating You

A static API key is only half of the agent identity problem. Workload identity federation kills the key — the agent proves it runs in your infrastructure with a short-lived token instead of a secret that lives in an environment variable. That's the machine hop: agent-to-platform, solved.

The other hop is quieter, and most stacks haven't touched it. Whose name is on the calls the agent makes after it has authenticated?

When your agent calls your CRM with your OAuth token, the CRM logs you. Every downstream system logs you. If that agent gets prompt-injected into exporting a customer list, the SIEM shows a legitimate employee running a legitimate export — your name, your access, 2 a.m. No field anywhere says a machine did this, unattended, because a web page told it to.

The OpenID Foundation's October 2025 whitepaper on agentic identity names the fix directly: user impersonation by agents should be replaced by delegated authority. The mechanism is older than the LLM boom — RFC 8693, OAuth token exchange, published and stable since January 2020. It puts two identities in one token: sub, the human who delegated, and act, the actor acting for that human. Most agent stacks have never heard of it. Most agent stacks are still impersonating you.

Impersonation breaks three things at once

OAuth access tokens are ambient authority. Whoever holds the token exercises its full scope — no proof of who's holding it, no per-call narrowing. Hand your token to an agent and you've handed over your entire authorization surface, and three security properties break at the same time:

• Accountability. The audit trail attributes every call to you. When the export happens, the incident review opens with "why did Alice pull forty thousand records?" — a question with no good answer, because Alice didn't.
• Least privilege. The agent inherits your scope in full. The token doesn't distinguish between the delegation you intended — read today's calendar — and everything else you're allowed to do. The agent can never hold less than you.
• Revocability. You can't turn off the agent without turning off you. Revoking its access means revoking your own.

This feels acceptable because the agent usually behaves. That's not a security property. That's a streak.

RFC 8693 draws the line between "I am Alice" and "I am Alice's agent, acting for Alice." The agent exchanges the base token at the authorization server for a new one that carries sub — Alice — and act — the agent. Every downstream service, and every log line, sees both. When the agent misbehaves, you attribute the action to the agent, revoke its actor identity, and Alice's own access never wobbles.

Impersonation is convenient right up until someone has to answer for it. Delegation costs one extra claim and buys back accountability, least privilege, and revocability in the same token.

The chain is recorded — and unenforced

Here's the part that should make you uncomfortable. RFC 8693 also defines how multi-hop delegation gets recorded: nested act claims, riding inside the token. Alice's agent delegated to a sub-agent, which delegated to another — the whole chain is in there. The catch is what RFC 8693 says resource servers should do with that chain. It's informational. No enforcement. No structural guarantee.

Unenforced audit trails attract attacks. Delegation chain splicing — disclosed to the OAuth working group mailing list on February 26, 2026 — does exactly that: a compromised intermediary presents a mismatched subject_token and actor_token from two different delegation contexts, and the authorization server mints a properly-signed token asserting a delegation chain that never happened. The signature validates. The audit trail is forged.

A signed token asserting a chain that never occurred is worse than no audit trail at all. It's a forged one — with your name on it.

The IETF's answer is stacking up in the WIMSE working group's credential delegation draft. Against splicing: signed delegation receipts at every hop, chained back to the root consent event, so a spliced token fails verification. Against ambient authority: capability-shaped tokens bound to specific operations and resources, DPoP proof-of-possession on every use, fifteen-minute recommended lifetimes, and cascading revocation — revoke the root, kill every token derived from it. Authority can only narrow as it flows down, and the narrowing is enforced by the delegation server, not by the agent asking nicely. It's a draft — the first one — but it aims at exactly the load-bearing weakness.

The rest of the pipeline is converging on the same shape. A March 2026 IETF draft (draft-klrc-aiagent-auth-00) proposes composing SPIFFE/WIMSE workload identity with OAuth so the access token carries the agent as client_id and the delegated user as sub. Microsoft's Entra Agent ID added an agent-specific on-behalf-of flow in 2026 that treats the agent as a first-class actor in the exchange, not an invisible intermediary. Different bodies, same conclusion: two identities, separately named, in every token.

What actually shipped

The drafts are drafts. Two things are not:

MCP closed the token passthrough hole. The June 18, 2025 spec revision made MCP servers OAuth resource servers and requires clients to implement Resource Indicators (RFC 8707): every token request names its intended audience, and servers must reject tokens minted for someone else. That kills token passthrough — an MCP server forwarding your token to a third-party API, which then trusts whoever handed it over and logs you for the call. Audience-bound tokens don't solve delegation. They do remove the confused-deputy reuse that made borrowed credentials so valuable to attackers in the first place.

The platform layer exists. Entra Agent ID, Anthropic's Claude Platform federation (June 2026), and the SPIFFE/WIMSE stack all ship agent-native identity today. The primitives are stable RFCs — token exchange, resource indicators, workload identity. What's missing is assembly. Teams waiting for the IETF to finish are running impersonation on purpose in the meantime.

What you can ship this week

1. Find where the agent borrows credentials. Agent configs, .env files, CI secrets, MCP server configs — anywhere the agent holds your token or a service account key that acts as you. The AI Agent Config Checker scans agent and MCP configs for static credentials before you migrate anything.

2. Give the agent its own principal. A registered agent identity — not your token, not a shared service account. If the agent runs in infrastructure you control, it already has one; workload identity federation converts it into short-lived credentials.

3. Delegate, don't impersonate. If your identity provider supports RFC 8693 token exchange, use it: exchange the base token for one carrying sub — you — and act — the agent — scoped below your own access. If your IdP doesn't support it yet, that's the feature request to file; Entra's agent OBO flow shows the shape.

4. Enforce audience binding at every hop. MCP servers must reject tokens minted for a different audience; your internal services should do the same. A token that works everywhere belongs to whoever holds it.

5. Read your own tokens. Pull one downstream access token out of your logs — the one your agent used against the CRM this morning. Decode it with the JWT Decoder; it runs entirely in your browser, nothing uploaded. No act claim? Your agent is impersonating someone. You already know whose name is in sub.

What this doesn't fix

Be honest about the boundaries, because they're where the next incidents will live.

The splicing fix is a draft. RFC 8693 itself is unchanged. Signed receipts live in an Internet-Draft, not a standard. Until authorization servers adopt chain verification, an act chain in a signed token is a claim, not proof.

Your internal APIs ignore act. A resource server that doesn't know the claim doesn't enforce it — it reads sub and proceeds. Delegation claims stay advisory until every hop checks them, and the weakest link is whichever service nobody updated.

MCP's auth model doesn't carry delegation. The OAuth profile binds tokens to audiences. It does not encode the user-agent relationship into the token. What the agent does with your authority after the MCP handshake is still your architecture's problem.

None of it prevents the injection. Prompt injection via indirect context is how agents get told to misuse their access. Delegation doesn't stop the instruction — it bounds the damage and makes it attributable. To see how far a compromised agent can actually reach from one node, score your deployment with the Agent Boundary Assessment — it's the multi-agent boundary checklist from your-multi-agent-graph-has-no-boundaries, as 16 questions in your browser.

The pattern

The log entry from the top of this post — your name, 2 a.m., forty thousand records — should have read the agent's name, acting for you. Nothing in that sentence requires new cryptography. RFC 8693 has been published since 2020, the platform layer shipped this year, and the one-time cost is an exchange call plus a claim your downstream services agree to check.

Impersonation makes the agent invisible. Delegation gives it a name — and a name is something you can scope, audit, and revoke.

Decode the token before the incident decodes it for you.