The Week That Fragmented Agent Identity
In the first week of May 2026, the RSA Conference became the accidental launch pad for a standards collision. CrowdStrike announced its Agent Attestation Framework (AAF). Cisco released a draft of its Agentic Identity Mesh specification. Palo Alto Networks published the Cortex Agent Trust Protocol (CATP). Microsoft released version 1.0 of its Secure Agent Communication standard under the Azure AI umbrella. And Cato CTRL, the threat research arm of Cato Networks, published a white paper on its proposed cross-vendor Agent Principal Registry.
All five launched within four days. None of them are compatible. Each uses different trust anchors, different token formats, different revocation mechanisms, and different identity claim schemas. An agent built for one ecosystem cannot authenticate to a service built for another without custom bridging code — which itself becomes an attack surface.
Meanwhile, the IETF's working group on agent authorization has produced three competing Internet-Drafts: one extending OAuth 2.1 with agent-specific claims, one proposing a new Verifiable Agent Credential (VAC) format independent of OAuth, and one arguing for building agent identity on top of existing SPIFFE/SPIRE workload identity primitives. None have reached RFC status. None are expected to reach it before 2027 at the earliest.
| Vendor | Framework | Trust Anchor | IETF Alignment |
|---|---|---|---|
| CrowdStrike | AAF | Platform attestation | Partial — JWT-based |
| Cisco | AIM | Network identity mesh | None stated |
| Palo Alto | CATP | Policy-as-code enforcement | Partial — SPIFFE-derived |
| Microsoft | SAC | Azure AD managed identity | OAuth 2.1 extension |
| Cato CTRL | APR | Cross-vendor registry | Proposed new draft |
Why Fragmentation Is a Security Problem
Protocol fragmentation in agent identity is commonly described as an interoperability problem — the kind of thing that eventually gets sorted out by a working group producing a common standard, after which everyone adopts it over the next several years. That framing misses the security dimension that makes the current situation acutely dangerous.
When there is no single standard for what constitutes a valid agent identity assertion, every cross-ecosystem interaction degrades to a choice between two bad options: reject the foreign agent entirely (breaking the use case) or accept it on weaker-than-desired trust grounds (bridging code, identity translation layers, or simply trusting the agent's self-assertion). Identity translation layers are particularly dangerous — they are typically thin wrappers that accept one credential format and re-assert the identity in another, without fully validating the security properties of the original credential.
The multi-protocol confusion attack exploits this directly. An attacker crafts an agent identity token that is well-formed under Protocol A but carries claims that Protocol B's translator will interpret differently — specifically, claims that Protocol A marks as informational but Protocol B elevates to authorization-bearing. The translation layer sees a valid token and produces a valid-but-incorrect assertion on the other side. Neither protocol individually is at fault; the fault lies in the gap between them.
A documented attack class from Lyrie Research's Q1 2026 report involves agents that bridge between Azure SAC and a SPIFFE-native environment. The SAC token carries an agent_capabilities extension claim that the SAC validator treats as advisory metadata. The SPIFFE-to-SAC bridge, implemented by a third-party vendor, maps agent_capabilities to SPIFFE SVID attributes — interpreting the advisory metadata as authorization claims. An attacker who can write to the agent_capabilities field (trivially possible for agents that self-register in the SAC ecosystem) can inject elevated capability claims that the bridge will forward as valid SPIFFE authorization. The vulnerability exists entirely in the translation layer, not in either underlying protocol.
The IETF Draft Landscape
The three competing IETF Internet-Drafts reflect genuine technical disagreements about what agent identity should be, not just political fragmentation between vendors.
The OAuth 2.1 extension draft argues that agent identity is fundamentally a delegation problem and should be solved within the existing OAuth framework — specifically, by formalizing the use of RFC 8693 token exchange for agent-to-agent delegation and adding a new agent_id claim to standard JWT token formats. Its strength is backward compatibility with existing OAuth infrastructure. Its weakness is that it treats agent identity as a subset of user identity, which fails for fully autonomous agents acting without a delegating human.
The Verifiable Agent Credential draft takes the opposite position: agent identity is fundamentally different from human identity and should be expressed in a purpose-built credential format based on W3C Verifiable Credentials. VACs are self-contained, cryptographically verifiable identity documents for agents that include capability attestations, operational context, and revocation status. The format is more expressive than JWT extensions allow, but requires deploying new credential infrastructure that nothing currently supports.
The SPIFFE extension draft argues for building agent identity on top of workload identity primitives already widely deployed in cloud-native environments. SPIFFE SVIDs (X.509 certificates with workload identity URIs) are already used for service-to-service authentication in Kubernetes and service mesh environments. The draft proposes extending SPIFFE to carry agent-specific attributes. The practical advantage is adoption: organizations already running SPIFFE can extend it incrementally. The limitation is that SPIFFE is designed for static workload identity, not the dynamic per-task identity semantics that agentic systems require.
# What five different protocols assert for "the same" agent identity # CrowdStrike AAF { "aat": "crowdstrike-aaf-v1", "agent_id": "agt_9f2a", "platform_attestation": "..." } # Microsoft SAC (OAuth 2.1 extension) { "sub": "agent:scheduling-v2", "azp": "azure-ad-app-id", "agent_capabilities": ["email:send"] } # SPIFFE-based (CATP partial alignment) spiffe://org.example/ns/default/sa/scheduling-agent # in X.509 SAN # VAC draft (W3C Verifiable Credential) { "@context": ["https://www.w3.org/2018/credentials/v1"], "type": ["VerifiableCredential", "AgentIdentityCredential"], "credentialSubject": { "agentId": "did:agent:scheduling-v2" } } # Cross-vendor pipeline requires bridging all four — each bridge is an attack surface
What a Unified Standard Actually Needs
The technical requirements for agent identity are not actually contested — the disagreements are about implementation approach. A workable standard needs to satisfy five properties that current proposals satisfy in different combinations but none satisfy completely.
First, dynamic identity: agent credentials must be per-task or per-session, not static workload identities. An agent running the same code for different users on different tasks should have distinct identity tokens for each execution. Second, delegation provenance: the credential must carry a verifiable chain from the agent identity to the human principal who ultimately authorized the task. Third, capability binding: the credential must cryptographically bind the agent's stated capabilities to what it is actually authorized to do — claims and authorizations must be the same thing. Fourth, universal revocation: any agent credential must be revocable instantly, with that revocation propagating to all resource servers that might act on it. Fifth, cross-domain verifiability: an agent in Organization A must be able to present its identity to a resource in Organization B in a way that Organization B can verify without calling back to Organization A's infrastructure.
No current proposal satisfies all five. OAuth extension satisfies 1 and 2 poorly, 5 reasonably. VAC satisfies 1, 2, and 3 well, 4 and 5 not yet. SPIFFE satisfies 3 and 5 well, 1 and 2 poorly. The vendor frameworks each optimize for their own deployment environment and fail on cross-domain verifiability almost by design.
The Interim Security Position
The standards will not converge before 2027 at the earliest. Organizations building agent systems now must make pragmatic choices in the absence of consensus. The key principle for the interim period is to treat cross-protocol identity boundaries as untrusted perimeters, regardless of what the receiving system claims to verify.
Choose one identity protocol for your internal agent ecosystem and enforce it consistently — mixed-protocol environments multiply attack surface. Document every identity translation layer explicitly; these are your highest-risk trust boundaries. Treat translated credentials as "verified with caveats" — log them separately and apply stricter scope limits to agents that authenticated via translation. Audit translation layer implementations against the source protocol's security model: specifically check whether advisory claims are being elevated to authorization-bearing claims in translation. Prefer OAuth 2.1 extension for new builds if your identity infrastructure is already OAuth-based — it has the highest density of existing validation tooling. Monitor the IETF drafts for convergence signals; a merged draft or strong adoption of one approach will likely appear by mid-2027. Budget for a credential migration when a standard does emerge — credential formats will need to change.
Fragmentation as Attack Surface
It is tempting to treat the current protocol fragmentation as a temporary inconvenience that the market will resolve. The historical pattern for authentication standards suggests otherwise. SAML, OAuth, OpenID Connect, and FIDO2 each coexisted for years with incompatible predecessors, and each coexistence period produced incidents that would not have been possible in a unified environment. The OAuth 1.0-to-2.0 transition created an entire class of vulnerabilities in hybrid deployments. The SAML-to-OIDC migration is still ongoing a decade after OIDC's publication and is still producing misconfiguration vulnerabilities at scale.
Agent identity fragmentation will follow the same pattern. The difference is that the agent ecosystem is moving much faster than prior authentication transitions, and the agents themselves can act autonomously in ways that amplify credential vulnerabilities before human operators detect them. A misconfigured identity translation layer in an OAuth-to-AAF bridge is not just an interoperability bug — it is a potential for automated, large-scale unauthorized action before anyone notices that the wrong agent presented the wrong credentials to the wrong resource.
The pressure to converge on a standard is real. So is the window of time during which fragmentation itself is the most significant agent identity risk. Organizations shipping agents into production in 2026 are shipping into that window. The security properties of every cross-protocol interaction they rely on are, at best, a careful best effort.