The Agent Identity Gap: Why MCP and A2A Need Verifiable Delegation
Your agent just called a tool. Which agent authorized it? Through how many hops? With what budget? Can you prove any of this after the fact?
You can't. Not today.
The problem is obvious. The fix isn't.
MCP lets agents call tools. A2A lets agents talk to other agents. Neither verifies who the agent is. A Knostic scan of roughly 2,000 MCP servers found every single one lacked authentication.
MCP added OAuth 2.1 this year, which helps for single-hop client-to-server auth. But when an orchestrator delegates to a specialist that calls a tool, OAuth authenticates the last hop. The delegation chain that led there? Gone. No record. No constraints. No audit trail.
This matters because multi-agent systems are becoming the default architecture. An orchestrator decomposes a task. Specialists execute. Sub-agents handle edge cases. Each handoff is a trust boundary with no identity flowing across it.
Invocation-Bound Capability Tokens
The Agent Identity Protocol (AIP) addresses this with a single token that answers four questions at once.
Who authorized this? The root authority block, signed by the human or system that started the chain.
Through which agents? Each delegation appends a block that narrows scope. You can delegate "search only, $1 budget, 3 hops max" and the token enforces it cryptographically. Scope can only narrow, never widen.
What constraints applied? Datalog policy evaluation at each hop. Simple mode generates the rules for you. You specify values, the library writes the Datalog.
What was the outcome? An optional completion block records the result hash, cost, and verification status, linking authorization to provenance.
Two wire formats serve different needs:
Compact mode is a JWT with EdDSA signature. Single hop. Standard JWT libraries can verify it. Drop it into an MCP server in 10 minutes.
Chained mode uses Biscuit tokens with append-only blocks. Multi-hop delegation with scope attenuation at every level. Each block is signed independently. The chain is tamper-evident.
Does it actually work?
Real MCP deployment. AIP adds 0.22ms of overhead to a real HTTP tool call. Sub-millisecond identity verification on every request.
Real LLM multi-agent chain. With Gemini 2.5 Flash handling the inference, AIP accounts for 0.086% of total end-to-end latency. Less than a tenth of a percent. Identity is not the bottleneck.
Adversarial security. 600 attacks across 6 categories: scope widening, depth violation, token replay, wrong key, empty context, token forgery. 100% rejection rate. Two of those categories (delegation depth violation and audit evasion through empty context) are uniquely caught by AIP. Plain JWT deployments miss them entirely.
Why not just use OAuth? Or DIDs? Or SPIFFE?
I surveyed 11 existing approaches. Each gets something right but misses something essential for agent delegation:
OAuth requires a central authorization server per trust domain. No holder-side attenuation.
W3C DIDs need blockchain and wallets. Agents are software, not humans.
Macaroons use shared secrets. Every verifier becomes a potential forger.
SPIFFE requires dedicated infrastructure. Incompatible with ephemeral agent creation.
Biscuit gets the token format right but has no identity resolution, no protocol bindings, no provenance model.
AIP builds on Biscuit's cryptographic foundation (Ed25519, Datalog, append-only blocks) and adds what's missing: an identity scheme, MCP/A2A/HTTP bindings, completion blocks for provenance, and a compact JWT mode for simple cases. The full comparison is in the paper (Table 1, seven dimensions across eleven approaches).
Why identity is the foundation
Identity is not just an authentication feature. It is the layer that makes other trust properties possible.
Consider provenance. In prior work on multi-agent routing, I found that self-claimed quality routing performs worse than random selection when delegates can inflate their scores. This is the provenance paradox: unverified quality metadata is not just noisy, it is actively harmful. The fix is structural. The protocol needs to distinguish between self-claimed, runtime-observed, and externally-attested quality. But that distinction is meaningless without verifiable identity. If you cannot verify who produced an output, you cannot verify whether their quality claim was attested by a credible third party.
The same applies to routing. Identity-aware routing achieves roughly 12x lower latency on easy tasks by sending them to lightweight models. But routing decisions depend on knowing what model is behind an agent. Without verifiable identity, those model properties are unattested claims.
And it applies to collective reasoning. Structured deliberation produces typed reasoning traces: which agent asserted what, which challenges were raised, how disagreements resolved. Those traces are only auditable if you can verify which agent contributed which argument.
Identity is Layer 1 because nothing above it works without it.
What's next
The paper is on arXiv: arXiv:2603.24775
The code is open source: github.com/sunilp/aip
Reference implementations in Python (primary SDK) and Rust. Apache 2.0 license. Cross-language interoperability verified.
Three things I want to explore next:
- Validating the A2A binding against real agent-to-agent workflows
- Formalizing the provenance bridge (linking authorization chains to quality evidence)
- A controlled comparison against a real OAuth 2.1 baseline
If you are building multi-agent systems on MCP or A2A, I'd like to hear what identity problems you are running into. The protocol is designed to be practical, not theoretical. Feedback on real use cases is the fastest way to make it better.