The identity boom
The industry solved agent identity five different ways. Then it stopped.
Over the past eighteen months, every major agent protocol shipped its own identity model. Each one is internally coherent. Each one is incompatible with the others. The result is not a standards war — it is five parallel universes that do not acknowledge each other's existence.
AGNTCY/SLIM uses Agent Badges built on W3C Verifiable Credentials with DID-based naming. Agents carry JSON-LD enveloped VCs containing metadata, schema definitions, and authentication information. It is the most cryptographically rigorous model — and the most complex to implement.
Google A2A uses Agent Cards with optional JWS digital signatures, added in v0.3 (July 2025). Authentication runs through OAuth 2.0, with formalized per-task short-lived tokens. Agent Cards are JSON documents describing capabilities, endpoints, and supported interaction modes.
Anthropic MCP uses OAuth 2.1 with PKCE for authorization. Agents are not first-class identity holders — MCP is a tool protocol, not an agent-to-agent protocol. Identity is derived from the OAuth flow, not from the agent itself.
ACP (BeeAI, Linux Foundation) uses REST HTTP for agent communication. Its documentation is notably sparse on security — no explicit identity, authentication, or signing mechanisms are documented. Agents are addressable by URL. That is the extent of the identity model.
ANP (Agent Network Protocol) uses W3C DIDs with the did:wba method, private key signing, and mandatory DID-WBA authentication. Every agent interaction begins with cryptographic identity verification.
| Protocol | Identity Model | Signing | Cross-Protocol Interop |
|---|---|---|---|
| AGNTCY/SLIM | Agent Badges (W3C VCs + DIDs) | VC signatures | No |
| Google A2A | Agent Cards + OAuth 2.0 | JWS (optional) | No |
| Anthropic MCP | OAuth 2.1 + PKCE | OAuth tokens | No |
| ACP (BeeAI) | REST HTTP (URL-based) | None documented | No |
| ANP | W3C DIDs (did:wba) | Private key signing | No |
Five protocols. Five identity models. Zero interoperability between any of them.
Six drafts, no standard
The IETF has at least six individual Internet-Drafts addressing agent identity and authorization. All are fragmented. None have been adopted by any IETF working group.
- draft-yl-agent-id-requirements — Digital Identity Management for AI Agent Communication
- draft-klrc-aiagent-auth — AI Agent Authentication and Authorization, leveraging WIMSE and OAuth 2.0
- draft-ni-a2a-ai-agent-security-requirements — Security Requirements for AI Agents
- draft-goswami-agentic-jwt — Agentic JWT, an OAuth 2.0 extension for autonomous agents
- draft-oauth-ai-agents-on-behalf-of-user — OAuth 2.0 for AI agents acting on behalf of users
- draft-nandakumar-agent-sd-jwt — SD-JWT encoding of Agent Cards for privacy-preserving discovery
These drafts are not converging. They represent competing approaches from different authors and organizations, each pulling agent identity toward a different substrate — OAuth extensions, JWT profiles, DID-based systems, selective disclosure mechanisms.
Meanwhile, the W3C AI Agent Protocol Community Group formed in May 2025, held its first meeting in June 2025, and has projected specification timelines into 2026-2027. The Agentic AI Foundation (AAIF), a Linux Foundation project formed in December 2025 with Anthropic, Block, OpenAI, Google, Microsoft, AWS, and Cloudflare, has active working groups on governance, security, and observability — but no trust or identity specification published yet. NIST launched an AI Agent Standards Initiative in February 2026, focused on identity as a starting point.
Everybody knows the problem exists. Nobody has converged on a solution. Fragmentation is not a temporary phase — it is the default state, and it is hardening as each protocol's identity model gets embedded deeper into production systems.
The interop problem
An AGNTCY agent carrying a Verifiable Credential badge cannot prove its identity to an A2A agent expecting a signed Agent Card. An MCP client authenticating via OAuth 2.1 has no mechanism to verify a DID-authenticated ANP agent. An ACP agent addressed by URL has no cryptographic identity at all — it simply is whatever responds at that endpoint.
This is not a theoretical gap. Multi-protocol is already reality. AGNTCY has 75+ member organizations. A2A has 150+ supporters. MCP has AAIF backing and broad adoption across development tooling. These ecosystems overlap — the same enterprises deploy agents using multiple protocols, often within the same workflow.
As agents start crossing organizational boundaries — Company A's procurement agent negotiating with Company B's sales agent, a healthcare coordinator querying a pharmacy fulfillment system — they will need to verify each other's identity across protocol boundaries. No mechanism exists for this today. The agent at the other end of the connection is, cryptographically speaking, whoever it claims to be.
The payment networks already see this coming. Visa's Trusted Agent Protocol (TAP) uses agent-specific cryptographic signatures to establish trust between AI agents conducting financial transactions. Mastercard's Verifiable Intent builds a "tamper-resistant cryptographic record" linking identity, intent, and outcome for agent-mediated commerce — backed by FIDO Alliance, EMVCo, IETF, and W3C standards, with Google, Fiserv, IBM, and Checkout.com as partners.
When money moves through agents, identity verification becomes non-optional. Visa and Mastercard are not waiting for an IETF working group to adopt a draft. They are building their own trust infrastructure because the stakes demand it.
The audit trail that doesn't exist
EU AI Act Article 12 requires automatic logging of events over the AI system's entire lifetime. Logs must enable identifying risk situations, support post-market monitoring, and facilitate operation monitoring. The minimum retention period is six months.
Article 12 was written for single AI systems with identifiable providers. It does not address:
- Accountability across multi-agent interactions where multiple providers' systems collaborate
- Unified audit trails across distributed agents running on different infrastructure
- Tracing causality through delegation chains where Agent A asks Agent B to instruct Agent C
- Identity verification of agents acting autonomously across organizational boundaries
High-risk provisions enforce August 2, 2026. That is five months away.
No agent protocol or framework defines a tamper-evident audit trail format for multi-agent interactions. Every protocol defines message delivery — how bytes move from sender to receiver. None define "who communicated with whom, what was delegated, what decisions resulted, and how to reconstruct the chain of custody." The logging that Article 12 requires for single systems becomes exponentially harder when the "system" is a dynamic coalition of agents from different organizations, running different protocols, with no shared identity or record-keeping format.
The penalty structure reflects how seriously the EU takes this: fines of up to 35 million euros or 7% of global annual turnover for the most serious violations. For context, 7% of a Fortune 500 company's revenue is not a compliance cost — it is an existential threat.
The trust stack
Identity, encryption, and audit are not competing priorities. They are complementary layers of a trust stack that does not yet exist as an integrated whole.
| Layer | Question | Today's State |
|---|---|---|
| Identity | Who is this agent? | 5 incompatible models, 6 IETF drafts |
| Attestation | What is it authorized to do? | Visa TAP (commerce only), no general standard |
| Encryption | Can anyone else read the conversation? | TLS only in most protocols (covered in "The Encryption Gap") |
| Audit | What happened and can we prove it? | No standard format exists |
The gap is not any single layer — it is the absence of a stack that works across protocols.
Identity without encryption means you know who is talking but anyone with infrastructure access can listen. Encryption without identity means the conversation is private but you cannot verify who is in it. Both without audit means there is no evidence when something goes wrong. And all three without cross-protocol interoperability means the trust stack only works within a single protocol's ecosystem — which is not how multi-agent systems are being built.
Each layer reinforces the others. MLS group encryption (the subject of our previous post) provides forward secrecy and post-compromise security for agent channels — but MLS group membership requires identity verification. A tamper-evident audit trail requires both: you need to know who the participants are (identity) and ensure the trail itself cannot be read or modified by unauthorized parties (encryption). Strip out any layer and the others lose their guarantees.
What comes next
Three forces will drive convergence. None of them are voluntary.
A cross-protocol incident. An agent spoofing identity across protocol boundaries is not a hypothetical — it is an inevitability given the current architecture. MCP tool poisoning attacks, documented by Invariant Labs, already demonstrate how lack of identity verification enables malicious tools to exfiltrate data by injecting instructions into tool descriptions that override agent behavior. The attack surface expands dramatically when agents from different protocols interact without a shared trust mechanism. The question is not whether a cross-protocol identity spoof will happen, but whether it will be detected when it does.
Regulatory enforcement. EU AI Act Article 12 will be tested. When regulators ask "your multi-agent system made this decision — show us the audit trail," most organizations will have nothing that satisfies the requirement. The audit trail problem is inseparable from the identity problem: you cannot log who did what if you cannot verify who the participants were. The first enforcement action against a multi-agent system will clarify what "appropriate cybersecurity" means in practice, and it will not mean "TLS between microservices."
Payment network pressure. Visa and Mastercard are building agent trust infrastructure for commerce because financial transactions require non-repudiation. Their standards — cryptographic agent signatures, verifiable intent records, tamper-resistant delegation chains — will not stay confined to payments. When the payment networks establish that agents conducting transactions must carry verifiable credentials and produce auditable records, those requirements will cascade into procurement, supply chain, healthcare, and every other domain where agents cross organizational boundaries. Standards follow money.
The organizations that build cross-protocol trust infrastructure now — identity verification, encrypted channels, tamper-evident audit — will have a structural advantage over those that wait for a standard to emerge. Standards follow adoption. They do not precede it.
Further reading
- RFC 9420: The Messaging Layer Security (MLS) Protocol
- IETF draft-yl-agent-id-requirements: Digital Identity Management for AI Agent Communication
- EU AI Act Article 12: Record-Keeping
- Visa Trusted Agent Protocol
- Mastercard Verifiable Intent
- AGNTCY Identity Specification
- A2A Protocol Specification
- The Encryption Gap: AI Agent Security's Blind Spot
- Invariant Labs: MCP Tool Poisoning Attacks