{"slug": "mcp-agent-to-agent-vulnerabilities-what-google-s-flaw-reveals-about-protocol", "title": "MCP Agent-to-Agent Vulnerabilities: What Google's Flaw Reveals About Protocol-Level Security Boundaries", "summary": "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.", "body_md": "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.\n\nRecent 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.\n\nMCP 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.\n\nWhen agents start calling other agents' tools, that model breaks:\n\nThis 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.\n\nThe disclosed flaw exploited MCP's lack of caller verification. An attacker could:\n\nThe attack surface exists because MCP has no way to answer: \"Should this agent be allowed to invoke this tool on behalf of this user?\"\n\nThe protocol defines three message types:\n\n```\n{\n  \"jsonrpc\": \"2.0\",\n  \"method\": \"tools/call\",\n  \"params\": {\n    \"name\": \"read_file\",\n    \"arguments\": {\n      \"path\": \"/etc/passwd\"\n    }\n  }\n}\n```\n\nThe 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.\"\n\nFor human-driven workflows, this works. The human is the security boundary. They choose which MCP servers to trust.\n\nFor 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.\n\n| Security Primitive | Traditional RPC | REST API | MCP (current) | What Agents Need | \n|---|---|---|---|---|\n| Caller identity | Service principal | OAuth client ID | None | Agent ID + provenance | \n| Authorization | ACLs, RBAC | Scopes, claims | None | Capability tokens | \n| Audit logging | Standard | Standard | Optional | Required + tamper-proof | \n| Rate limiting | Per-client | Per-token | None | Per-agent + per-tool | \n| Revocation | Certificate/token | Token refresh | Connection close | Fine-grained capability revocation | \n\nIf you're building agent infrastructure on MCP today, you need to add security layers the protocol doesn't provide:\n\n**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.\n\n``` python\nclass SecureMCPClient:\n    def __init__(self, agent_id, signing_key):\n        self.agent_id = agent_id\n        self.signing_key = signing_key\n\n    def call_tool(self, server, tool_name, arguments):\n        # Create signed claim\n        claim = {\n            \"agent_id\": self.agent_id,\n            \"tool\": tool_name,\n            \"timestamp\": time.time()\n        }\n        signature = hmac.new(\n            self.signing_key,\n            json.dumps(claim).encode(),\n            hashlib.sha256\n        ).hexdigest()\n\n        # Inject into MCP call\n        return mcp_client.call(\n            server,\n            tool_name,\n            {**arguments, \"_auth\": claim, \"_sig\": signature}\n        )\n```\n\n**Server-side authorization**: MCP servers must validate caller identity and check permissions before executing tools. Don't rely on connection-level trust.\n\n**Capability tokens**: Issue short-lived tokens that grant specific agents access to specific tools. Revoke tokens when agent behavior becomes suspicious.\n\n**Observability**: Log every cross-agent tool invocation with caller ID, tool name, arguments (sanitized), and result status. Feed this into your SIEM.\n\nMCP's security issues get worse in multi-tenant environments:\n\nThe protocol has no concept of isolation domains. You have to build that yourself.\n\nWhen running agent-to-agent MCP in production, watch for:\n\nA secure agent-to-agent protocol needs:\n\nThese aren't optional features. They're table stakes for any protocol that crosses trust boundaries at scale.\n\n**Use MCP for agent-to-agent communication when:**\n\n**Avoid MCP for agent-to-agent communication when:**\n\nThe 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.\n\nThe 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.", "url": "https://wpnews.pro/news/mcp-agent-to-agent-vulnerabilities-what-google-s-flaw-reveals-about-protocol", "canonical_source": "https://dev.to/mech_app_ai/mcp-agent-to-agent-vulnerabilities-what-googles-flaw-reveals-about-protocol-level-security-23d2", "published_at": "2026-10-08 00:08:20+00:00", "updated_at": "2026-10-08 00:17:00.721367+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-safety", "ai-infrastructure", "developer-tools"], "entities": ["Model Context Protocol", "Anthropic", "Google"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/mcp-agent-to-agent-vulnerabilities-what-google-s-flaw-reveals-about-protocol", "markdown": "https://wpnews.pro/news/mcp-agent-to-agent-vulnerabilities-what-google-s-flaw-reveals-about-protocol.md", "text": "https://wpnews.pro/news/mcp-agent-to-agent-vulnerabilities-what-google-s-flaw-reveals-about-protocol.txt", "jsonld": "https://wpnews.pro/news/mcp-agent-to-agent-vulnerabilities-what-google-s-flaw-reveals-about-protocol.jsonld"}}