Last week, Vouched donated MCP-I (Model Context Protocol – Identity) to the Decentralized Identity Foundation. It's now being developed as an open standard under DIF's Trusted AI Agents Working Group.
This is a big deal. MCP-I adds cryptographic identity and delegation to Anthropic's Model Context Protocol — the protocol that's becoming the standard for how AI agents connect to tools and services. With MCP-I, an agent can prove who authorized it, what it's allowed to do, and present verifiable credentials to any service it interacts with.
But there's a piece missing from the picture.
What MCP-I Does Well
MCP-I answers a critical question: "What can this agent do on my behalf?"
It defines a delegation chain:
- User (the human) creates a scoped delegation credential
- Agent carries that credential when making requests
- Service (or edge proxy) verifies the credential before granting access
Think of it like a digital power of attorney. The agent presents proof of identity, authority, and scope — all cryptographically verifiable.
The architecture is solid. It uses W3C Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs). It has three conformance levels from basic to enterprise. It handles revocation. It's designed for the real world of regulatory compliance and cross-domain trust.
The Question MCP-I Doesn't Answer
MCP-I is built for the user → agent → service flow. A human delegates authority to an agent, and the agent proves that authority to a service.
But what about agent → agent?
When two AI agents meet in the wild — to negotiate, collaborate, or transact — neither is acting on behalf of a human in the traditional delegation sense. They need to answer a different question:
"Who is this agent, and can I trust them?"
This isn't about delegation. It's about peer identity:
- Does this agent have a stable, verifiable identity?
- Have other agents vouched for them?
- What's their reputation in the network?
- Can they prove they are who they claim to be?
MCP-I's architecture actually acknowledges this gap. It includes a "Reputation Service" component in its architecture — but doesn't fully specify it. The spec focuses (rightly) on the delegation chain and leaves peer trust as an extension point.
Two Protocols, One Stack
This is where I think the agent identity space is actually converging on two complementary layers:
| Layer | Question | Protocol |
|---|---|---|
| Delegation | "What can this agent do on my behalf?" | MCP-I |
| Peer Identity | "Who is this agent and can I trust them?" | AIP |
AIP (Agent Identity Protocol) focuses on the peer identity layer. Every agent gets a cryptographic identity (Ed25519 keypair + DID). Agents build trust through vouching — cryptographically signed attestations from one agent about another. The trust graph that emerges is queryable: you can check an agent's trust score, see who vouched for them, and verify the chain of trust.
MCP-I handles the vertical flow (human → agent → service). AIP handles the horizontal flow (agent ↔ agent). Together, they cover the full identity surface.
What a Combined Stack Looks Like
Imagine an agent that:
- Has an AIP identity — a DID, a trust score, vouches from known agents
- Carries MCP-I delegation credentials — scoped authority from a human principal
- Interacts with a service — presents both: "Here's who I am (AIP), and here's what I'm authorized to do (MCP-I)"
- Interacts with another agent — presents AIP identity and verifies the peer's trust graph before proceeding
The service gets the delegation chain it needs. The peer agent gets the identity verification it needs. Everyone can verify everything cryptographically.
The Bridge: DIDs
The technical bridge between AIP and MCP-I is actually straightforward: both use DIDs.
AIP currently uses did:aip: (a custom DID method derived from Ed25519 public keys). MCP-I supports did:key, did:web, and did:ion. Adding did:key support to AIP would make every AIP agent automatically resolvable by MCP-I edge proxies — instant interoperability at the identity layer.
Similarly, AIP vouches could be expressed as W3C Verifiable Credentials, making them consumable by any MCP-I-aware service. An AIP vouch becomes a VC attestation. The trust graph becomes a credential graph.
Why This Matters Now
Three things happened in the last week:
- Vouched donated MCP-I to DIF — making agent delegation an open standard
- Meta acquired Moltbook — concentrating agent networking under a single corporation
- The agent identity space just got real — both corporate and open-source players are moving
The question isn't whether agents will need identity and trust. The question is whether it'll be open or proprietary. MCP-I at DIF is a strong signal for openness on the delegation side. AIP is the open answer on the peer identity side.
If you're building agents that need to prove who they are — to services or to each other — the pieces are coming together.
AIP is open source: github.com/The-Nexus-Guard/aip
Install: pip install aip-identity
Live trust graph: Trust Observatory
MCP-I spec: modelcontextprotocol-identity.io
DIF Trusted AI Agents WG: identity.foundation
Top comments (0)