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.
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.
Adesh Gairola, Founder, raxIT Labs
Four Stones, No Path Yet. Four dressed stones set in line across the water below a willow thicket, with a rope running back to a post on the near shore and nothing cut into the far bank.
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 happens, every credential an AI agent carries needs a tamper-proof, signed format the other side can check, the same idea as a passport with a hologram. If you cannot trust the document itself, nothing built on top of it means anything. This is the boring layer most enterprise identity teams already run today, so it rarely needs new tooling. A JWT is the signed token itself, the ID card. JWKS is the set of public keys that verifies a JWT's signature. OIDC and OAuth 2.1 are the login-and-consent plumbing almost every enterprise already uses somewhere. Get this bottom layer wrong and every layer stacked above it, workload proof, delegation, discovery, inherits a forged foundation that no cryptography further up the stack can repair.
The question: is this actually the thing we think it is, not an imposter?
An agent runs as some process on some machine, and this layer cryptographically proves which workload is running, with no shared password sitting around waiting to leak, a tamper-proof fingerprint for the running software. One caveat matters later: this layer proves the workload, not the agent's reasoning. It tells you the right program is running. It does not tell you the program is thinking straight. The real name here is SPIFFE and SPIRE, which hand a workload a short-lived, attested ID called an SVID, so no long-lived secret sits 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, the version most enterprise platforms will likely ship next.
The question: who authorized this, and through which agents?
This layer is what is actually new for agents, and the easiest part to get wrong. Agents act for people, and they hand work to other agents in turn: a human asks Agent A, which asks Agent B, which calls a tool, and by the time the request reaches that tool the human and the path behind it are gone, so the tool just sees "some agent." The answer, and the one call worth getting right, is delegation, not impersonation. The human stays the subject of the request, each agent that touches it rides along as a named actor rather than borrowing the human's own token, and the whole chain from human to tool gets recorded, so an audit log can show who authorized the action and every agent that carried it along the way.
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.
{ "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 has never seen, the old path was to fill in a signup form and paste in an API key, a flow built for a human sitting at a browser with a mouse. An agent instead hits a locked door, a 401 response, and has no idea what to do next. This top layer is how an agent discovers how to authenticate and onboards itself to that unfamiliar service, with no human around to paste in a key on its behalf. The real names behind it are RFC 9728, a service's machine-readable page that spells out how you log in, along with MCP auth and auth.md, which let an agent read that page and register itself on the spot.
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. I later found a real case of it: what happens when the binding is missing, the layers above all check out and the wrong human still ends up in the token. A permission set that wide, sitting on an identity nobody's watching, is also just excessive agency in the 2026 list by another name.
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? The wider guide, covering delegation, accountability and the exploit that showed what identity alone misses, sits at AI agent identity.
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
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.