The Identity Mesh: Federated Trust for Multi-Agent AI

A human proves who they are once per session, and mostly through judgment. You check an ID, recognize a face, or trust a mutual contact, then build confidence over repeated interactions. AI agents get none of that. An agent has to prove, in milliseconds, to a system it has never met, that it is who it claims to be and that it is allowed to do what it is about to do. Then it has to do that again, thousands of times a minute, often on behalf of another agent that is acting on behalf of a person.

That is the problem I keep running into as agents move from demos into real workflows. A single agent answering questions is easy to secure. The value shows up when agents collaborate across systems and across companies: your marketing agent hands a lead to a partner's procurement agent, which checks pricing with a supplier's inventory agent, with no human in the loop. The moment agents cross an organizational boundary, the identity stack we built for humans and services starts to buckle.

Why agents break traditional identity

SAML and OpenID Connect were built for people who log in occasionally, complete an interactive flow, and hold a session. Agents violate every one of those assumptions. They authenticate continuously, cannot click a consent screen, and operate in environments where what they are allowed to do changes minute to minute.

Delegation is where it gets genuinely hard. Your agent authorizes a logistics agent to read shipping data. That agent delegates an inventory check to a supplier's agent. Each hop needs to preserve who originally asked, what they are allowed to do, and who is accountable if it goes wrong. Traditional tokens do not carry that. An OAuth access token is opaque: it says a request is authorized, but not by whom, on whose behalf, or how many hands it passed through. Once you hand it off, the receiver cannot narrow its scope or see the chain behind it.

So the real question is not "can this agent authenticate." Authentication is close to solved. The question is "on whose authority, and how far does that authority reach." That is an authorization and delegation problem, and it is still open.

The stakes are higher than they were for microservices because agents act on their own initiative and can create real liability. When a service in your own cluster misbehaves, you own the whole system and can trace it. When an agent three hops away, inside a partner's infrastructure, makes a bad call using authority that traces back to your user, the questions of who authorized it and who pays are not academic.

What an identity mesh actually means

Strip away the buzzwords and an identity mesh is a simple idea: instead of one central gatekeeper deciding who trusts whom, every participant can independently verify every other participant. Traditional security looks like a castle. Everyone inside the walls is trusted, everyone outside is suspect. That model assumes clear, stable boundaries. Agents dissolve those boundaries in real time.

A mesh works more like passports and consulates. Each organization stays sovereign over its own agents and its own rules, but they agree on formats and cryptographic checks that let a stranger's credential be verified without a phone call to headquarters. Three things have to travel with an agent for that to work: a verifiable identity, a scoped and time-bound grant of what it can do, and enough provenance to reconstruct the delegation chain after the fact.

None of that requires a blockchain, despite how often the two get bundled together. It requires signed credentials, short-lived tokens, and standards everyone agrees to read the same way.

What actually exists in 2026

Here is the honest state of the tooling, because a lot of writing on this topic blurs shipping standards with wishlist.

MCP and A2A cover the wire, not identity. The Model Context Protocol, which agents use to call tools, adopted OAuth 2.1 (with PKCE and resource indicators) for its authorization spec. Google's Agent2Agent protocol, which agents use to talk to each other, reached v1.0 under the Linux Foundation, which has hosted it since June 2025, and passed 150 supporting organizations with a steering committee that includes AWS, Cisco, Google, IBM, and Microsoft. A2A deliberately does not invent an identity system. It reuses existing schemes (OAuth 2.0, OpenID Connect, mutual TLS) that each agent declares in its "agent card," and v1.0 added signed agent cards so you can verify the card's issuer. The takeaway: these protocols secure the connection. Neither one verifies the identity of the agent behind it or the chain of delegation in front of it.

And having a standard is not the same as using it. Security researchers who scanned roughly two thousand public MCP servers in early 2026 found that essentially none enforced authentication at all. The spec exists; the deployments lag it badly. So even the part we call solved is only solved on paper until teams actually turn it on.

SPIFFE and SPIRE handle workload identity. SPIFFE gives workloads a cryptographic identity instead of a shared API key, and it is being applied to agents. The limits are real: SPIRE needs dedicated infrastructure, X.509 issuance is slow relative to agents that spin up and die in seconds, and SPIFFE addresses identity inside an infrastructure boundary. It does not carry identity across the MCP-to-A2A hop between organizations.

The IETF is standardizing the missing middle. The WIMSE working group (Workload Identity in Multi-System Environments) is the serious effort here. Its drafts define workload identity architecture, workload proof tokens, and, importantly, token exchange and transaction tokens: mechanisms to convert one token into a narrower, context-bound token as a request crosses a boundary. That is the shape of a real answer to the delegation problem, and it builds on OAuth's RFC 8693 token exchange, which A2A already leans on.

The gap nobody has closed yet

Put those pieces together and you can see the seam. We can authenticate an agent. We can secure the channel. What we still cannot do cleanly, across organizations, is pass a grant of authority down a chain so that each hop can only ever narrow it, never widen it, and so the last agent in the chain still proves who first authorized the work.

Concretely, a delegation chain needs to behave like this:

user -> agent A            (can read orders, spend up to $500)
     -> agent B            (can read orders only)      <- narrowed
     -> partner agent C    (can check one SKU)         <- narrowed again

Every arrow should attenuate the grant, never expand it, and C's request should still be traceable back to the original user. Opaque OAuth tokens cannot express that on their own, which is why token exchange, proof tokens, and scope attenuation are the parts of the stack getting the most attention right now. This is also where a mesh earns its keep: revocation. When one agent is compromised, that fact has to propagate fast, and partial revocation (kill its payment scope, keep its read scope) has to be expressible. Certificate revocation lists were never built for that tempo.

What is emerging, and what is still speculation

Several standards-track pieces are close enough to build on. W3C Verifiable Credentials let an agent carry a portable, signed claim ("this agent is certified to process EU financial data") that any party can check without calling the issuer. OpenID Connect Federation reduces the manual work of establishing trust between many organizations. Both are real and usable today.

Then there is a wave of research and early drafts: proposals for agent identity protocols that span MCP and A2A, capability tokens that fuse identity, attenuated authorization, and provenance into a single append-only chain, and an IETF draft for an Agent Name Service. These are promising and worth tracking. They are also drafts and papers, not settled standards. If you read a vendor pitch that presents any of them as the way it works, treat that as a roadmap, not a fact.

I want to be blunt about two ideas that get oversold. Blockchain smart contracts as the "immutable registry" for agent identity solve a coordination problem that signed credentials and existing registries already solve with less overhead and lower latency, and latency is exactly what ephemeral agents cannot afford. Zero-knowledge proofs are real and useful cryptography, and privacy-preserving verification of agent claims is a legitimate research direction. But the notion that agents will routinely prove their capabilities through zero-knowledge challenges today is aspirational. The math exists; the standardized, interoperable agent plumbing does not. Build on the OAuth and SPIFFE layers that ship. Watch the rest.

How to prepare without overbuilding

You do not need a federation network to get ready for one. The useful work is mostly internal and mostly boring, which is a good sign.

Start with workload identity inside your own walls. Give every agent a real cryptographic identity instead of a static key, using SPIFFE or your platform's equivalent, on low-risk workloads first. Adopt OAuth 2.1 for how your agents call tools, since that is where MCP already landed. Wherever an agent acts for a user or another agent, capture the delegation explicitly: who authorized this, for what scope, until when. Even if your tokens cannot yet carry the full chain, logging it gives you the audit trail regulators are going to ask for.

Then keep the boundary honest. Prefer short-lived, narrowly scoped grants over long-lived broad ones. Make sure an agent can never widen the authority it was handed. Build revocation you can trigger in seconds, not on a certificate's expiry schedule, and rehearse it, because the first time you test kill-switching a rogue agent should not be during an incident. Do that and, when the cross-organization standards firm up, federation becomes a matter of connecting to partners rather than re-architecting from scratch.

The takeaway

The industry has quietly solved the easy half of agent identity. MCP, A2A, SPIFFE, and OAuth 2.1 can prove an agent is authentic and secure the channel it talks over. The hard half, passing scoped authority down a multi-hop chain across organizations without losing accountability, is still being written, mostly inside the IETF's WIMSE work and the OAuth token-exchange machinery around it. An identity mesh is not a product you buy or a ledger you deploy. It is a discipline: every agent gets a verifiable identity, every grant is narrow and short-lived and only ever narrows as it is delegated, and every hop is traceable. Get those habits into your own systems now, on the standards that actually ship, and skip the blockchain. When the cross-org pieces land, you will be ready to plug in instead of starting over.