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.
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:
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.
The disclosed flaw exploited MCP's lack of caller verification. An attacker could:
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?"
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.
| 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 |
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):
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()
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.
MCP's security issues get worse in multi-tenant environments:
The protocol has no concept of isolation domains. You have to build that yourself.
When running agent-to-agent MCP in production, watch for:
A secure agent-to-agent protocol needs:
These aren't optional features. They're table stakes for any protocol that crosses trust boundaries at scale.
Use MCP for agent-to-agent communication when:
Avoid MCP for agent-to-agent communication when:
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.