The Model Context Protocol (MCP) is becoming the default wire format for agent-to-agent communication. Anthropic designed it, major vendors adopted it, and now security researchers have found structural flaws in how it handles trust boundaries when one agent calls another agent’s tools.
Recent vulnerability disclosures affecting Google and other major agent platforms expose a fundamental problem: MCP was built for human-to-agent interaction, but it’s being deployed for agent-to-agent invocation without the authentication, authorization, or sandboxing primitives that scenario requires.
The Trust Model Gap
MCP defines how agents expose tools (functions, data sources, prompts) to clients. The protocol assumes a single trust boundary: the client (typically a human using Claude Desktop or similar) decides which MCP servers to connect to, and those servers expose capabilities.
When agents start calling other agents’ tools, that model breaks:
- No caller identity: MCP servers see tool invocations but don’t know which agent made the call
- No capability tokens: There’s no standard way to scope what tools an agent can invoke on another agent
- No audit trail: The protocol doesn’t require logging of cross-agent invocations
- Ambient authority: If an agent can connect to an MCP server, it can call any tool that server exposes
This is the opposite of how modern RPC systems work. gRPC has interceptors for auth. REST APIs have OAuth scopes. Even older systems like CORBA had security service specifications.
How the Google Vulnerability Worked
The disclosed flaw exploited MCP’s lack of caller verification. An attacker could:
- Craft a malicious MCP server that advertises legitimate-looking tools
- Convince a target agent to connect (via prompt injection, misconfiguration, or social engineering)
- Have that agent invoke tools on other MCP servers it trusts
- Use the target agent as a confused deputy to access resources it shouldn’t
The attack surface exists because MCP has no way to answer: “Should this agent be allowed to invoke this tool on behalf of this user?”
What MCP Actually Provides
The protocol defines three message types:
{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "read_file",
"arguments": {
"path": "/etc/passwd"
}
}
}The server responds with results. There’s no session token, no capability list, no proof of authorization. The security model is: “If you can send the message, you can invoke the tool.”
For human-driven workflows, this works. The human is the security boundary. They choose which MCP servers to trust.
For agent-to-agent workflows, it fails. Agents don’t have the context to make trust decisions, and they operate at machine speed across organizational boundaries.
Architecture Comparison
| Security Primitive | Traditional RPC | REST API | MCP (current) | What Agents Need |
|---|---|---|---|---|
| Caller identity | Service principal | OAuth client ID | None | Agent ID + provenance |
| Authorization | ACLs, RBAC | Scopes, claims | None | Capability tokens |
| Audit logging | Standard | Standard | Optional | Required + tamper-proof |
| Rate limiting | Per-client | Per-token | None | Per-agent + per-tool |
| Revocation | Certificate/token | Token refresh | Connection close | Fine-grained capability revocation |
Implementing Defense in Depth
If you’re building agent infrastructure on MCP today, you need to add security layers the protocol doesn’t provide:
Agent identity layer: Wrap MCP connections with a sidecar that injects caller identity into every tool invocation. This can be a simple HTTP header or a signed JWT in the message metadata.
class SecureMCPClient:
def __init__(self, agent_id, signing_key):
self.agent_id = agent_id
self.signing_key = signing_key
def call_tool(self, server, tool_name, arguments):
# Create signed claim
claim = {
"agent_id": self.agent_id,
"tool": tool_name,
"timestamp": time.time()
}
signature = hmac.new(
self.signing_key,
json.dumps(claim).encode(),
hashlib.sha256
).hexdigest()
# Inject into MCP call
return mcp_client.call(
server,
tool_name,
{**arguments, "_auth": claim, "_sig": signature}
)Server-side authorization: MCP servers must validate caller identity and check permissions before executing tools. Don’t rely on connection-level trust.
Capability tokens: Issue short-lived tokens that grant specific agents access to specific tools. Revoke tokens when agent behavior becomes suspicious.
Observability: Log every cross-agent tool invocation with caller ID, tool name, arguments (sanitized), and result status. Feed this into your SIEM.
The Deployment Shape Problem
MCP’s security issues get worse in multi-tenant environments:
- Shared MCP servers: If multiple agents connect to the same MCP server (common for database access, file systems, or API gateways), one compromised agent can abuse tools on behalf of others
- Cloud deployment: MCP servers running in containers or serverless functions often share network namespaces, making network-level isolation insufficient
- State leakage: MCP servers that maintain state between tool calls can leak information across agent boundaries
The protocol has no concept of isolation domains. You have to build that yourself.
Failure Modes to Monitor
When running agent-to-agent MCP in production, watch for:
- Confused deputy attacks: Agent A tricks Agent B into calling tools Agent A shouldn’t access
- Privilege escalation: Agent gains access to tools by chaining through multiple MCP servers
- Resource exhaustion: Malicious agent floods MCP servers with tool calls
- Information disclosure: Agent extracts sensitive data by invoking diagnostic or introspection tools
- Prompt injection via tool results: MCP server returns malicious content that hijacks the calling agent’s next action
What the Spec Should Include
A secure agent-to-agent protocol needs:
- Mandatory caller authentication: Every tool invocation must identify the calling agent
- Capability-based authorization: Servers must be able to grant and revoke fine-grained permissions
- Audit requirements: Protocol must specify what gets logged and how
- Isolation primitives: Clear boundaries for multi-tenant deployments
- Revocation mechanism: Way to invalidate compromised agent credentials without restarting servers
These aren’t optional features. They’re table stakes for any protocol that crosses trust boundaries at scale.
Technical Verdict
Use MCP for agent-to-agent communication when:
- You control both agents and can add authentication layers
- You’re running in a single-tenant environment with strong network isolation
- You have comprehensive logging and can detect anomalous tool invocations
- You’re willing to build capability management on top of the base protocol
Avoid MCP for agent-to-agent communication when:
- You’re exposing tools to third-party agents you don’t control
- You need fine-grained authorization or compliance audit trails
- You’re running multi-tenant infrastructure without additional isolation
- You can’t modify the agents to add security wrappers
The protocol works for its original use case (human-driven agent interaction), but it’s not ready for agent-to-agent invocation without significant security additions. Treat it like HTTP: useful transport layer, but you need to add auth, encryption, and access control yourself.
The Google vulnerability isn’t a bug in an implementation. It’s a structural flaw in deploying a protocol outside its security model. If you’re building agent infrastructure, assume MCP provides zero security guarantees and layer your own on top.