MCP connects tools. A2A connects agents. Neither one knows who it's talking to.
The agentic stack is assembling fast. In the span of eighteen months, two open protocols have emerged to solve the plumbing problems of autonomous AI: Anthropic's Model Context Protocol (MCP) gives agents a standard way to reach tools and data sources. Google's Agent2Agent Protocol (A2A) gives agents a standard way to talk to each other.
Both are important. Both are necessary. And both have the same blind spot.
Neither protocol answers the most basic question one system can ask another:
*Who are you, and why should I trust you?*
The stack as it stands
Think of the emerging agentic infrastructure in three layers:
The tool layer — MCP. MCP standardizes how an agent connects to external resources. Databases, APIs, file systems, code execution environments. Before MCP, every integration was bespoke. Now there's a shared protocol. An agent that speaks MCP can discover and use tools without custom glue code. This is solved, and solved well.
The communication layer — A2A. A2A standardizes how agents find and delegate work to other agents. A client agent publishes a task; a remote agent picks it up, processes it, and returns results. Agent Cards describe capabilities. JSON-RPC handles transport. The Linux Foundation governs the spec. Agent-to-agent communication now has a common language.
The identity layer — ?
This is the gap. When an MCP server receives a connection, it knows what the agent wants to do. It doesn't know who the agent is. When an A2A client delegates a task to a remote agent, it can read the Agent Card — name, capabilities, endpoint. But an Agent Card is self-reported. There's no independent verification. No accumulated reputation. No way to distinguish an agent that's been operating responsibly for six months from one that was spun up five minutes ago.
MCP is plumbing. A2A is a phone line. But nobody's checked IDs.
Why identity is the missing primitive
Consider the scenarios already playing out:
Agent-to-agent delegation. A planning agent finds three specialist agents via A2A that can handle a research task. All three have Agent Cards. All three claim the right capabilities. How does the planning agent choose? Today, it can't — not on any basis beyond self-reported metadata. With persistent identity and trust scores, the planning agent can verify: this agent has been registered for four months, has completed 2,300 tasks, has a trust score of 0.84, and has signed a non-malicious covenant. That other one was registered yesterday with no history.
MCP server access control. A company exposes internal tools via MCP. Any agent that speaks the protocol can attempt to connect. The MCP spec handles capability negotiation — but not identity verification. Who is this agent? Who deployed it? What's its track record? Without an identity layer, MCP servers are open doors with no bouncer.
Multi-agent systems. Frameworks like CrewAI, AutoGen, and LangGraph orchestrate teams of agents working together. Inside a single deployment, trust is implicit — the developer controls all the agents. But the moment agents from different organizations, different frameworks, different trust boundaries need to collaborate, implicit trust breaks down. You need portable, verifiable credentials that travel with the agent.
Accountability and audit. When something goes wrong in a multi-agent workflow — and it will — who's responsible? If every agent is anonymous, the answer is no one. Persistent identity creates a chain of accountability. An agent with a Cloud Passport has a declared purpose, a signed covenant, and a reputation that can be inspected after the fact.
These aren't hypothetical problems. They're the problems that emerge the moment agentic systems move from single-developer prototypes to cross-organizational production.
Where Cloud Passports fit
Citizen of the Cloud is not a replacement for MCP or A2A. It's the layer beneath both — the identity infrastructure they assume exists but don't provide.
A Cloud Passport is a signed, portable credential that an agent carries across platforms and protocols. It contains:
- A unique, persistent Cloud ID
- A declared name and purpose
- An autonomy level classification
- A cryptographic signature (Ed25519)
- A non-malicious covenant status
- A trust score that accrues over time based on observed behavior
The passport is verifiable by anyone. It's not tied to a single platform, framework, or provider. An agent with a Cloud Passport can present its identity to an MCP server, to an A2A remote agent, to a CrewAI crew, or to any system that wants to know who it's dealing with.
Here's how the three layers compose:
┌─────────────────────────────────────────────┐
│ APPLICATION / FRAMEWORK │
│ (LangGraph, CrewAI, AutoGen, custom) │
├─────────────────────────────────────────────┤
│ COMMUNICATION — A2A Protocol │
│ Agent discovery, task delegation, SSE │
├─────────────────────────────────────────────┤
│ TOOLS — MCP Protocol │
│ Database access, APIs, code execution │
├─────────────────────────────────────────────┤
│ IDENTITY — Cloud Passport (CotC) │
│ Persistent ID, trust score, verification │
└─────────────────────────────────────────────┘Identity sits at the foundation because every other layer benefits from knowing who it's interacting with. MCP becomes safer when servers can verify agent identity before granting tool access. A2A becomes more useful when Agent Cards are backed by independently verifiable credentials and earned reputation. Frameworks become more robust when multi-agent orchestration can make trust-informed decisions about delegation.
A concrete example
An enterprise deploys a multi-agent system using LangGraph. The orchestrator agent needs to:
1. Query a proprietary database via an MCP server 2. Delegate a research subtask to an external specialist agent via A2A 3. Return results to a human operator
Without the identity layer, steps 1 and 2 are trust-free zones. The MCP server accepts any connection that speaks the protocol. The A2A delegation goes to whichever agent matches the capability query — identity unknown.
With Cloud Passports in the stack:
Step 1: The orchestrator presents its Cloud Passport to the MCP server. The server checks the passport signature, verifies the trust score meets its threshold (say, 0.70+), and confirms the non-malicious covenant is signed. Access granted. If the passport is missing, revoked, or below threshold — access denied.
Step 2: The orchestrator queries A2A for specialist agents. Three respond with Agent Cards. The orchestrator cross-references each against the Cloud Passport registry: Agent A has a trust score of 0.81 with six months of history. Agent B has a trust score of 0.43 and was flagged last week. Agent C has no passport. The orchestrator delegates to Agent A.
Step 3: The results include a full identity chain — which agents participated, their passport IDs, their trust scores at time of execution. The human operator has an auditable record.
Nothing about this replaces MCP or A2A. It augments both. The protocols handle the what and the how. Cloud Passports handle the who.
The DNS analogy
In the early internet, machines could talk to each other via IP. They could serve pages via HTTP. But there was no reliable way to map names to addresses, no way to know whether a server was who it claimed to be. DNS and later TLS/PKI solved that. They didn't replace TCP or HTTP. They made them trustworthy.
The agentic web is at the same inflection point. MCP and A2A are the TCP and HTTP — essential transport and communication layers. But without an identity and trust layer, the agentic web will be a place where any agent can claim to be anything, and no agent can prove it.
Cloud Passports are the identity primitive for this new infrastructure. Open, portable, cryptographically verifiable, and designed to compose with the protocols already gaining adoption.
Getting started
Cloud Passports are live today. The spec is open (CC BY 4.0). SDKs are available for Python, JavaScript, Go, and Rust.
If you're building with MCP, A2A, or any agent framework — the identity layer is ready when you are.