MCP Agent-to-Agent Vulnerabilities: What Google's Flaw Reveals About Protocol-Level Security Boundaries

Security researchers have disclosed structural vulnerabilities in Anthropic's Model Context Protocol (MCP) affecting Google and other major agent platforms, exposing a lack of caller verification, authorization, and sandboxing when agents invoke one another's tools. Because MCP assumes a single human-driven trust boundary, any client that can send a tools/call message can invoke a tool, with no session token, capability list, or proof of authorization. The writeup recommends adding agent identity layers, server-side authorization, short-lived capability tokens, and per-invocation audit logging to secure agent-to-agent deployments.

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. python 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. 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.