One note a month on AI security, from the people building the harness
What went wrong in the world, what it means for your agents, and what we changed because of it. No product announcements.
Reading progress: 0% complete
What went wrong in the world, what it means for your agents, and what we changed because of it. No product announcements.
AI agent identity answers who this is and whether it's allowed in. It does not answer whether what it did was okay. This guide covers what agent identity is, why traditional IAM breaks for agents, the delegation-versus-impersonation decision, the four-layer identity model, seven identity mechanisms compared by the audit log line each one leaves behind, how identity failed in the ServiceNow BodySnatcher case, and what identity cannot solve on its own.
Adesh Gairola, Founder, raxIT Labs
Every Gate Sound. A row of dressed-stone gateposts marking a shallow river crossing one after another, each pair sound and complete, the causeway running level through all of them toward the far bank.
Microsoft's Entra docs never use the word impersonate. They ship four access modes for an agent identity, and one of them is delegated access: "Agents can act on behalf of human users, using access rights given to the user. The user has control over which rights are delegated to the agent identity." Each identity is minted from an agent identity blueprint, a template that provisions agent identities at scale, separate from the service principals ordinary apps use. That's delegation, the shape this field has spent a year arguing for, built into the biggest enterprise directory there is.
Okta, Ping and SailPoint all land in roughly the same place: give the agent a credential, govern it like an account. None of that is wrong. It's just answering the easy half.
Every vendor selling AI agent identity can already tell you which agent made a call, and not one of them can tell you the call was fine. The definition worth holding is the one that keeps the human who asked inside the record, and admits, out loud, what proving identity still does not prove.
I run raxIT Labs. We build AI agent security and governance tooling, and we spend most of our time watching what deployed agents actually do at runtime, on top of whichever identity model issued them. This guide covers what agent identity is, where the standard answer stops, and where the real work starts.
AI agent identity is the set of credentials, claims and cryptographic proofs that answer two questions about a piece of autonomous software: who is this, and is it allowed in.
An AI agent is software that acts on its own: it books the flight, files the ticket, opens the pull request, hands a sub-task to another agent. Human identity systems assume a person at a keyboard. Service identity systems assume predictable code calling predictable APIs. An agent is neither. It decides in the moment, acts for a person who is not watching, and passes work to other agents in turn, so who this is and whether it's allowed gets hard fast.
The version of this I actually see in a customer's log the first week is smaller and uglier than the definition above: one row where the actor field is blank and the only name on the line belongs to a person who was asleep when the action fired.
That is the part every vendor page gets right. Agent identity answers who and allowed-in. It was never built to answer whether the specific thing the agent just did was a good idea.
Traditional identity and access management assumes a human clicking a button, or a service running code someone wrote. It breaks on four points once the actor is an agent.
It behaves non-deterministically, deciding in real time rather than executing a fixed path, so you cannot pre-assign every permission it will need.
It acts autonomously. Told to "handle my travel arrangements," it decides for itself what that authorizes, and the first sign of what it decided is the credit card statement.
It lives and dies fast, spinning up and shutting down in minutes rather than the months a service account survives, breaking provisioning cycles built around quarterly access reviews.
And it crosses organizational boundaries, needing to prove itself to a company that has never heard of it and shares no identity provider with the one that created it.
Put together, those four points are why an OAuth token issued for a human clicking through a consent screen does not map cleanly onto a system that spawns sub-agents on its own schedule. It's the exact gap the OpenID Foundation's 33-page whitepaper on agentic identity is built to close, and its own recommendation is blunt: "user impersonation by agents should be replaced by delegated authority." I worked through each of these breaking points in full in delegation vs. impersonation.
Yes in family, no in consequence. An AI agent is a non-human identity in the same sense a service account or a CI pipeline is: it authenticates without a password, and it should get its own credential rather than borrowing someone else's.
It stops being just another service account because a service account is deterministic. A human wrote down what it does, and it does that and nothing else. An agent decides in the moment, so it can be talked into something its own input suggested, in a way a cron job never can.
A cron job cannot decide to be somebody. Anthropic's own Fable 5.1 system card records a subagent that started its work already claiming a person's name, not a system prompt telling it to. Nobody assigned that actor field. The model wrote it. That is not a service account making a mistake. That is an agent choosing, mid-task, to stop being itself.
Governing it purely as an NHI covers the lifecycle half of the problem and leaves the decision half untouched.
Agents are non-human identities and they already outnumber the humans in most companies many times over, so of course they get their own credential. The argument was never about whether an agent should have an identity. It is about whether that identity floats free of the human who asked, or stays tied to them. An identity with no human behind it is just a very fast, very confident blank.
An agent can take one of three shapes, and only one keeps a human's name on the record. Impersonation means the agent borrows a person's own token and becomes them for the call. Acting as itself means the agent has its own identity, usually a service account, and the human who triggered it drops out of the log entirely. Delegation means the agent has its own identity and still carries the human forward as the party it is acting for.
Delegation is the one an auditor can work with: it's the only shape where the record names both the authority and the actor.
Three shapes, one action, three different lines in the log. Pick the shape by the line you want to be reading nine months later.
Anthropic's Claude Tag chose a third answer in practice: acting as itself, with a per-channel service account and no personal credentials involved. Pick a standard like PCI DSS, which wants every action tied to a named individual, and a channel service account is a shared account by design. There is no name to hand a regulator.
The steelman is real, though. Long-running agent work often has no single human behind it to delegate from, and delegation leaks anyway when an agent fetches something on one engineer's token while three other people read the same channel. Anthropic's own roadmap describes an "identity-aware overlay" checking both the channel's standing and the requesting user's own permission, delegation walking back in through a side door. Aembit calls that combination blended identity. I worked through this shift, including the confused-deputy problem a shared compartment creates, in how one model reasons about acting as itself.
I reach for delegation by default and only drop to acting-as-itself when there is genuinely no single human to name: a shared on-call channel, a scheduled job nobody owns. I have not seen a good answer for whose name belongs on the log line once an agent spawns a sub-agent three hops deep, including from us. The test I would still run on your own systems is the one I ran on Claude Tag: open your audit log, pick one agent action from today, and see whose name is actually on it.
A complete agent identity is four layers stacked on top of each other. An agent earns trust by climbing them in order.
Layer one is the token format, a tamper-proof, signed document like a JWT, checked against a public key set like JWKS, the same idea as a passport with a hologram. Layer two is workload proof, a cryptographic answer to "is this really the bot we think it is," typically SPIFFE or its emerging successor WIMSE, so no shared secret sits in a config file waiting to leak.
Layer three is the delegation chain, an actor claim under OAuth Token Exchange (RFC 8693) that keeps the human as the subject while naming every agent that carried the request. Layer four is discovery, how an agent onboards to a new service, through a machine-readable page like RFC 9728 plus MCP auth or WorkOS's auth.md.
Layer four's interesting problem this year is not the protocol, it's adoption. Knostic's scan of public MCP servers found 1,862 exposed instances; every one of the 119 they checked by hand skipped authentication entirely. The layer exists. Most of the field has not turned it on yet.
One worked request shows all four at once: an internal agent acting for Alice hits a third-party invoicing API cold and gets turned away with a pointer to the door it needs:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://api.vendor.com/.well-known/oauth-protected-resource"It follows that pointer, learns which authorization server to trust, and exchanges its own attested workload identity plus Alice's delegation for a token scoped to this one call. What comes back keeps Alice as the subject and names the agent as the actor:
{ "sub": "alice", "act": { "sub": "invoice-agent" }, "aud": "https://api.vendor.com", "scope": "invoices.read", "exp": "+5min" }No human pasted a key anywhere in that flow. I laid the full model out in the four-layer agent identity model. Climb all four and you have proven who the agent is and that it was let in the door. Nothing in that climb tells you whether it should have done what it did once it got there.
Pick the mechanism by what its audit log line can name, not by which one is easiest to wire up this sprint. A static key or a borrowed user token is the fastest thing to ship and the worst thing to still be running in a year, because neither log line can name the agent as distinct from whoever holds the credential.
An actor-chained OAuth exchange, a workload identity like SPIFFE, or a blended call checking both agent and human costs more to stand up, but it's the only family where your auditor can point at a log line and name an actor.
The rule underneath all seven rows: if a human asked, the mechanism needs to carry them forward in the record. If nobody asked, an agent acting under its own standing is fine, but the compartment it acted from is now the entire audit boundary.
Every vendor page describes what a mechanism proves. Few print the actual log line it leaves behind, the only artifact anyone opens after an incident, or name what it still cannot rule out even when it works exactly as designed. The table below does both.
api_key=sk-live-4f2… action=repo.read object=prod-dbactor=svc-claude@platform-eng action=repo.read object=prod-dbsub=alice action=repo.read object=prod-dbactor=claude on_behalf_of=alice action=repo.read object=prod-dbworkload=spiffe://prod/invoice-agent action=repo.read object=prod-dbclient_cert=CN=invoice-agent.prod action=repo.read object=prod-dbactor=svc-claude@platform-eng on_behalf_of=alice action=repo.read object=prod-dbRow three is the one that costs companies money. A borrowed token proves a human logged in at some point, nothing about who acted afterward. Two rows down, the OAuth actor chain closes that gap by keeping both names in the same line. Every row, including the newest and best of them, ends the same way: proving who acted is not the same claim as proving the action was fine.
The clearest public example is CVE-2025-12420, a ServiceNow vulnerability nicknamed BodySnatcher, where a hardcoded token shared across every instance combined with any employee's email address to bind an attacker to that person's identity, administrators included. Aaron Costello, who disclosed it, put the general lesson plainly: "AI agents significantly amplify the impact of traditional security flaws." Here that meant no gradual escalation; the attacker inherited full admin access in a single step.
Multi-factor authentication was on. Supervised execution was on. Both got bypassed because the failure sat one layer beneath them, at identity binding, the step that decides whose name gets attached to a session.
Both controls were switched on. Both were standing on the one step that never checked anything.
The logs were not missing or wrong. They were completely accurate, which is what makes the case worth studying: they showed an administrator creating a user, with nothing in the record to say an agent or an attacker was involved. That is a Layer 2 failure in the four-layer model above. I go through the exploit mechanics in the ServiceNow BodySnatcher case. The part that matters for identity: the token was never checked against anything, so every layer built on top of it inherited the same lie.
Four parties can end up accountable when an agent's action goes wrong: the organization that deployed it, whoever granted its permissions, the vendor who built it, and the model provider underneath. It almost never lands on the agent itself, since an agent cannot be sued, fired or fined.
Which of the four parties actually carries it is decided by evidence, not contract: whether a log line can show whose decision caused the action. By default that burden sits with the organization that deployed the agent, until it can point to a field that moves it elsewhere.
The fastest way to collapse all four of those claims at once is the failure this whole guide keeps returning to: an agent acting on a borrowed human credential, so the record carries a name with no way to tell whether a machine or a person was behind the decision.
Uber's production token shows the fix in one line, an actor chain that keeps every hop visible: { "sub": "user1", "act_chain": ["user1", "oncall-agent", "investigation-agent"], "aud": "mcp-gateway", "exp": "+5min" }. I built out the full six-row failure matrix, the evidence each row needs, and the field that carries it, in who's accountable when an agent acts. Whichever of the four parties ends up holding it, they hold it because the log could not point anywhere else.
A perfectly proven identity can still make a hijacked decision. A signed, audited, four-layer-compliant delegation chain can wrap around an agent that got prompt-injected into doing exactly the wrong thing, and identity cannot tell the difference: it was built to check who is acting, not what they decide.
The read-out of RSAC 2026 said this plainly: every vendor that shipped at the show verified who an agent was; none of them tracked what it actually did.
Simon Willison's lethal trifecta, private data, untrusted content, a way to send data out, is the clearest name for the failure mode identity cannot see. It checks that all three participants are who they claim to be and has no view of whether they combined into an exit route. That gap between credential proof and behavior is why OWASP's own resource on this is a threat taxonomy, not an identity standard.
There's a sharper version of this that identity alone cannot touch at all: composition. A database read is allowed. An email to an external address is allowed. Put them back to back and, if the read happened to touch a column with PII in it, the send should be denied, because the sequence is the breach and neither action on its own looked like one.
Two permitted actions. Denied because of the order they happened in. No identity token carries the field that decides this.
That is our own shape. The rule above is the one raxIT ships for this pattern, because identity answers a question about a single call, not the sequence around it. The research answer has a name: CaMeL tracks untrusted data through a run so it cannot reach an action without a permission check, taint tracking under a different hat.
Taint that survives a summarization step is a gap we have not closed. If an agent folds a tainted field into a paragraph before the next tool call, the taint can ride along in the wording without tripping the contains() check above. We catch some of this with narrower heuristics today, not a general answer.
This is denying the sequence rather than the action, and it is a runtime problem, not an identity one.
Telling you who an agent is will be close to a checkbox in every identity provider by the time Entra's agent blueprint and its rivals finish rolling out. The unsolved part sits one layer up: whether what the agent did with that identity was actually fine, which is where most of our own work at raxIT Labs lives.
Start with one question before any standard or vendor pitch: can you answer who did what, when, and why for a single agent action today? If not, that is the actual project, and everything else in this guide is plumbing under that sentence.
Two cheap rules for that plumbing, delegation over impersonation by default, and proving the whole chain on one real workflow before rolling it out everywhere, are in the four-layer model, so I won't repeat them here. The rule that guide skips is procurement. Price two vendors against whichever mechanism you land on from the table above before you sign: what a vendor can deliver shows up in their SDK before it shows up in their sales deck. Ask for the SDK first.
Sources: WorkOS auth.md · Uber: Solving the Identity Crisis for AI Agents · SPIFFE / SPIRE · JWT (RFC 7519) · JWKS (RFC 7517) · WIMSE architecture draft · OAuth 2.1 draft · OAuth Token Exchange (RFC 8693) · Protected Resource Metadata (RFC 9728) · Model Context Protocol · MCP authorization spec · OpenID Foundation: Identity Management for Agentic AI · Okta: what is AI agent identity · SailPoint agent identity security · Ping Identity: agentic AI · Microsoft Entra agent identities · Microsoft Entra agent blueprint · Knostic: mapping MCP servers · CVE-2025-12420 · AppOmni's BodySnatcher disclosure · Cedar policy language · CaMeL: defeating prompt injection with taint tracking · Simon Willison: the lethal trifecta · OWASP: agentic AI threats and mitigations · RSAC 2026 read-out (VentureBeat) · Claude Fable 5.1 system card · Claude Tag: an agent identity and access model (Anthropic) · Blended identity (Aembit) · the four-layer agent identity model · delegation vs. impersonation
Working out which layer your own agents' identity gap sits in, or what they actually do once they're inside? to discuss your specific deployment context and governance needs.
