The Identity Gap in Agentic AI
The Scale of What’s Coming
Section titled “The Scale of What’s Coming”By 2028, industry analysts project over 500 million autonomous AI agents operating across enterprise environments. These agents will negotiate contracts, manage infrastructure, process sensitive data, and make decisions with real-world consequences. They will delegate tasks to sub-agents, forming multi-layer hierarchies where authority flows through chains of automated systems.
And right now, almost none of them have a verifiable identity.
This is not a theoretical concern. Today’s agent frameworks — LangChain, CrewAI, AutoGen, the Model Context Protocol (MCP), Google’s Agent-to-Agent (A2A) — all focus on what agents do. None of them adequately address who agents are, what they are authorised to do, or how to prove it after the fact.
We are building an agent economy on an identity vacuum.
How Current Approaches Fall Short
Section titled “How Current Approaches Fall Short”When teams deploy agents today, they reach for familiar tools. Each one was designed for a different problem, and each one breaks in specific ways when applied to autonomous agents.
API Keys and Bearer Tokens
Section titled “API Keys and Bearer Tokens”The most common approach: give the agent an API key and call it a day.
API keys have no identity semantics. They are shared secrets that authenticate a request, not an entity. There is no way to express what the key holder is authorised to do beyond “access this API.” There is no delegation hierarchy — if Agent A passes its API key to Agent B, they become indistinguishable. And when something goes wrong, the audit trail shows a key, not an agent.
For a single agent calling a single API, this works. For a fleet of agents delegating to sub-agents across organisational boundaries, it is a liability.
OAuth 2.0 and Its Extensions
Section titled “OAuth 2.0 and Its Extensions”OAuth was designed for a specific interaction pattern: a human delegating access to an application. The human authenticates, consents, and the application receives a scoped token.
Agents break this model in several ways. First, there is no human in the loop for most agent-to-agent interactions. The client credentials grant handles machine-to-machine auth, but it was designed for known, pre-registered applications — not dynamically spawned agents. Second, OAuth has no concept of delegation chains. If Agent A delegates to Agent B, which delegates to Agent C, OAuth provides no mechanism to verify that chain or enforce scope narrowing at each step. Third, OAuth tokens carry no agent metadata — no model identifier, no runtime version, no configuration attestation.
The OAuth working group is aware of these gaps. Recent proposals for agent-oriented extensions are promising, but they are retrofitting agent semantics onto a protocol that was never designed for them.
SPIFFE/SPIRE
Section titled “SPIFFE/SPIRE”SPIFFE (Secure Production Identity Framework for Everyone) provides strong workload identity, and SPIRE is its production-grade implementation. For infrastructure workloads — containers, VMs, Kubernetes pods — SPIFFE works well.
But SPIFFE identifies workloads, not agents. A SPIFFE ID like spiffe://example.com/web-server identifies a process running on infrastructure. It carries no information about the AI model, its capabilities, its delegation authority, or its audit trail. SPIFFE has no delegation model and no concept of progressive trust. An agent either has an identity or it does not.
Custom Per-Vendor Solutions
Section titled “Custom Per-Vendor Solutions”Some agent platforms are building proprietary identity layers. These solve the immediate problem for their ecosystem but create vendor lock-in and interoperability walls. When Agent A (built on Platform X) needs to authenticate to Agent B (built on Platform Y), custom solutions offer no path forward.
What Agent-Native Identity Actually Requires
Section titled “What Agent-Native Identity Actually Requires”The gap is not just “identity for agents.” It is a specific set of capabilities that existing systems were not designed to provide:
Verifiable identity with agent metadata. An agent’s identity should carry its model, runtime, configuration hash, and trust level. A verifier should be able to determine not just who is making a request, but what kind of entity is making it.
Scoped, chainable delegation. When a human authorises Agent A, and Agent A delegates to Agent B, the system must enforce scope narrowing at every step. Agent B should not be able to exceed Agent A’s authority. And any verifier should be able to walk the chain back to the original human principal.
Tamper-evident audit trails. Every action an agent takes should produce a signed, hash-chained record that references the delegation token that authorised it. Not as an afterthought logging layer, but as a core protocol primitive that maps directly to compliance frameworks like NIST 800-53 and SOC 2.
Post-quantum cryptography from the start. Agent identity systems deployed today will still be operating when quantum computers become practical threats. Bolting on post-quantum cryptography later means re-issuing every identity, re-signing every delegation chain, and hoping nothing was harvested in the meantime.
Protocol composability. Agent identity should layer onto existing transports — MCP, A2A, HTTP — without requiring a new communication protocol. Agents already speak these protocols. Identity should travel alongside them.
IDProva: Purpose-Built for the Agent Era
Section titled “IDProva: Purpose-Built for the Agent Era”This is the problem IDProva was designed to solve. Rather than retrofitting human identity systems for agents, IDProva provides an agent-native identity layer built on three primitives:
Agent Identity Documents (AIDs) are W3C DID Documents extended with agent-specific metadata. Every agent gets a did:idprova: identifier carrying its public keys, model information, runtime version, configuration attestation, and trust level. The DID Document is the root of trust.
Delegation Attestation Tokens (DATs) are signed, scoped, time-bounded, revocable tokens that form verifiable delegation chains. Scope narrows at every step. Constraints inherit and tighten. Any verifier can trace authority from a leaf agent back to the human principal who started the chain.
Action Receipts are hash-chained, signed records of every action an agent performs. Each receipt references the DAT that authorised it, creating a complete attribution chain from action to identity to delegation to principal. The receipt format maps directly to NIST 800-53 AU-* controls, ISM logging requirements, and SOC 2 criteria.
IDProva is an open protocol, licensed under Apache 2.0. It uses hybrid Ed25519 + ML-DSA-65 signatures for post-quantum readiness from day one. It layers onto MCP and A2A without requiring protocol changes.
The Window Is Now
Section titled “The Window Is Now”Identity infrastructure is path-dependent. The patterns established in the next 18-24 months will define how the agent ecosystem handles trust for the next decade. We saw this with web identity — decisions made in the early 2000s around cookies, sessions, and OAuth still constrain what is possible today.
The agent era deserves an identity layer designed for its actual requirements: autonomous entities, multi-hop delegation, machine-speed interactions, and regulatory scrutiny. Not a retrofit. Not an extension. A purpose-built foundation.
The identity gap in agentic AI is not something that will solve itself. It requires deliberate protocol design, open standards, and an engineering community willing to treat agent identity as a first-class concern.
That is what IDProva provides. Get started today or read the protocol specification to understand the technical details.