Agent identity makes more sense as four stacked layers: a tamper-proof token format, cryptographic proof of which workload is running, a delegation chain that keeps the human as the subject, and a way to onboard to a service an agent has never met. Climb all four and you've proven who the agent is. You still haven't proven that what it did was okay.
The mental model that finally made agent identity make sense to me. Not how I think the world should see it. Just what clicked, plus the questions I use now with customers and to place vendors.
Almost every enterprise conversation I have at raxIT lands on the same question: how do we manage identity for AI agents at scale? And almost every time, the person answers it before I can. "Agent identity isn't a solved problem." If I had a nickel for every time I've heard that exact line, I'd be writing this from a nicer chair.
They're not wrong. But "not solved" isn't the same as "nothing to hold onto." Over the last few months I found a way to hold it. Here it is, plus the questions I ask now when someone says the line.
Quick setup, if this is new.
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. Our identity systems were built for two things: humans logging in, and predictable apps calling APIs. An agent is neither. It decides in the moment, acts for a person who isn't watching, and passes work to other agents. So "who is this, and is it allowed?" gets hard fast.
Seven months ago I wrote a long piece on why that breaks. It mapped the problem. It didn't show a way out.
This weekend two pieces of real, shipped work gave the way out a shape:
auth.md (by WorkOS's Garrett Galow), a way for an agent to register and log in to a service it's never met.They point in different directions. Reading both, the thing that made it click was to stop seeing agent identity as one blob and see it as four layers, stacked. A bot earns trust by climbing them, one at a time.
These four layers aren't an official standard or somebody's branded framework. They're the model I landed on to make the mess legible. I didn't invent the pieces underneath. The standards are everyone's. I just drew the lines and named them so the whole thing fits in your head.
It stands on two real ideas from the sources. One: the identity world keeps saying agent identity is really "workload identity plus delegation" (the long-running SPIFFE-versus-OAuth debate, now being formalized at the IETF). Two: Uber grounds identity from the bare compute up to the final token. I borrowed that shape. If a cleaner named framework exists, I haven't found it. And I'm not claiming this is how agent identity should work. It's the lens that made it legible for me. Could be wrong.
Bottom to top.
The four layers, bottom to top. Each layer builds on the one below, and a bot earns trust by climbing them.
The question: is this token even real, and unchanged?
Before anything clever, every credential an agent carries has to be in a tamper-proof, signed format the other side can verify. Think passport with a hologram. If you can't trust the document, nothing above it means anything.
This is the boring layer most shops already run. Real names: a JWT is the signed token (the ID card), JWKS is the set of public keys that verify the signature, and OIDC / OAuth 2.1 is the login-and-consent plumbing you use everywhere.
The question: is this actually the thing we think it is, not an imposter?
An agent runs as some process on some machine. This layer cryptographically proves which workload is running, with no shared password that can leak. A tamper-proof fingerprint for the running software.
One caveat, and it matters later: this proves the workload, not the agent's reasoning. It tells you the right program is running. It doesn't tell you the program is thinking straight.
Real name: SPIFFE / SPIRE, which hands a workload a short-lived, attested ID called an SVID. No long-lived secret sitting in a config file waiting to get stolen. SPIFFE is what runs in production today. The IETF is standardizing the same idea, vendor-neutral, as WIMSE, which is the version your platform will most likely ship.
The question: who authorized this, and through which agents?
This is the layer that's actually new for agents, and the one that's easiest to get wrong.
Agents act for people. And they hand work to other agents. A real request looks like: a human asks Agent A, which asks Agent B, which calls a tool. By the time it reaches the tool, the human and the path are gone. The tool just sees "some agent."
The rule here, and the one call I'd least want to get wrong: delegation, not impersonation. The tempting shortcut is to let the agent borrow the user's token and just be the user. One line of code, clean-looking logs, and it's often the only thing the tooling made easy. It's still a trap. Now your audit trail says Alice did something a machine decided, and if the agent gets hijacked, the attacker has all of Alice's access.
The right way: the human stays the subject, each agent rides along as a named actor, and the whole chain gets recorded.
{ "sub": "user1", "act_chain": ["user1", "oncall-agent", "investigation-agent"], "aud": "mcp-gateway", "exp": "+5min" }That's from Uber, in production, across thousands of agents, with the security check adding under 40ms. What a lot of us could only argue in theory now has a benchmark.
Real names: OAuth Token Exchange (RFC 8693), which carries an "act" / actor-chain claim recording every hop, and ID-JAG for acting for a user across different apps.
The question: how does an agent connect to something it's never met?
When an agent needs a service it's never seen, the old path was "fill in the signup form, paste an API key." Built for a human with a browser. An agent hits a locked door (a 401) and has no idea what to do next.
This top layer is how an agent discovers how to authenticate and onboards itself, no human pasting keys. Real names: RFC 9728 (a service's machine-readable "here's how you log in" page), MCP auth, and auth.md.
The uncomfortable part is how few of these doors are even locked yet. When Knostic scanned public MCP servers, roughly 41% still required no authentication at all in early 2026, and the raw number left exposed had gone up tenfold in a year.
Diagrams like the one above are easy to nod along with and hard to believe. So here is the whole climb in a single real request: an internal agent, acting for a user named Alice, reaching a third-party invoicing API it has never seen.
Alice asks the agent for her latest invoice. The agent calls the API cold and gets a door in the face, with a pointer to the keyhole (Layer 4):
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://api.vendor.com/.well-known/oauth-protected-resource"That resource_metadata pointer is RFC 9728. The agent follows it and reads how to get in:
{
"resource": "https://api.vendor.com",
"authorization_servers": ["https://id.vendor.com"],
"scopes_supported": ["invoices.read"],
"bearer_methods_supported": ["header"]
}Now it knows which authorization server to talk to. The agent already proved which workload it is (Layer 2, its SPIFFE SVID) and already holds a grant to act for Alice. It exchanges those for a token scoped to exactly this call (Layer 3, RFC 8693 token exchange):
POST /token HTTP/1.1
Host: id.vendor.com
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
subject_token=<Alice's delegation> # who it acts for
actor_token=<the agent's attested ID> # who is acting
audience=https://api.vendor.com
scope=invoices.read
# subject_token_type / actor_token_type omitted for brevity
Back comes a short-lived JWT (Layer 1, the format) whose claims keep Alice the subject and name the agent as the actor:
{ "sub": "alice", "act": { "sub": "invoice-agent" }, "aud": "https://api.vendor.com", "scope": "invoices.read", "exp": "+5min" }The agent retries with that token and gets the invoice. Four layers, one request: a signed format (L1) carrying a delegation chain (L3), minted off an attested workload (L2), to reach a service it discovered cold (L4). No human pasted a key. The log says Alice authorized it and the invoice-agent acted, not "some service did something."
And here is the part the whole climb cannot touch: nothing above stops the agent from being talked into reading the wrong invoice, or fetching the right one and mailing it somewhere it shouldn't. The token is perfect. The decision behind it might not be, and no part of this request can tell the difference.
None of this is new cryptography. Every layer is built from standards that already exist, most of them OAuth and IETF work bent into an agent shape. Here is the catalog, by layer, so you can see what actually fills each box and how settled it is (status checked May 2026). Skim it or skip it, the plain-English version is everything above.
Those two reads that point in different directions are working different layers.
Same four layers, two very different jobs. Most of the confusion is one group solving one layer and claiming they solved identity.
It's also how I place vendors now. Most cover one or two layers, not four. Working out which layer a tool actually lives in tells you fast what it can and can't do for you.
Climb all four perfectly and you've proven who the agent is and that it was allowed in. You still haven't answered what it does once it's inside, and whether that was okay.
Telling you who an agent is will be a free checkbox in your identity provider within a year or two. The hard, unsolved part moved one layer up, to authorization and behavior. A signed, audited delegation chain can sit wrapped around a completely hijacked decision. No cryptography tells you the agent reasoned honestly instead of getting tricked (prompt-injected) halfway through.
So don't let anyone sell you "agent identity, solved" because they nailed these four layers. That's the door. The room is still dark. I'm not the only one saying it. The read out of RSAC 2026 was blunt: every vendor on the floor could verify who an agent was, and almost none could tell you what it did.
That darker room, what did the agent actually do and can you prove it was fine, is where we spend our time at raxIT. Not because the four layers don't matter. Because they're the part you can buy, and this is the part you can't.
A fair note on us: raxIT is building in this space too, and our seat is watching what agents do rather than acting on anyone's behalf, which turns out to be a useful place to stand. We're adopting parts of this model internally. I'll write that up when we have something proven, not before. Right now this is just how we're thinking about it.
Not with a standard. Not with a vendor pitch. With one question:
Can you answer who did what, when, and why for a single agent action today? If not, that's the project. Everything else is plumbing under that sentence.
Then a few cheap, honest rules:
Seven months ago I had a map of the problem. This weekend I got the first real look at the answers, and a way to hold them: four layers to earn trust, and a fifth, darker question waiting at the top.
If you're starting from zero, which layer is your gap?
Sources: WorkOS auth.md · Uber: Solving the Identity Crisis for AI Agents · Uber's SPIFFE/SPIRE journey · SPIFFE / SPIRE · JWT (RFC 7519) · JWKS (RFC 7517) · OAuth 2.1 draft · OAuth Token Exchange (RFC 8693) · ID-JAG draft · Protected Resource Metadata (RFC 9728) · Model Context Protocol · raxIT: Identity Crisis in AI Agents
Working out which layer your agent identity gap sits in, or what your agents actually do once they're inside? to discuss your specific deployment context and governance needs.