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

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:

1. Craft a malicious MCP server that advertises legitimate-looking tools
2. Convince a target agent to connect (via prompt injection, misconfiguration, or social engineering)
3. Have that agent invoke tools on other MCP servers it trusts
4. 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:

1. Mandatory caller authentication: Every tool invocation must identify the calling agent
2. Capability-based authorization: Servers must be able to grant and revoke fine-grained permissions
3. Audit requirements: Protocol must specify what gets logged and how
4. Isolation primitives: Clear boundaries for multi-tenant deployments
5. 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.

Source Links

• Ars Technica: Vulnerability in agents from Google and others exposes structural flaw in MCP
• Hacker News Discussion

Comments

[tercel]

The wild part in that Ars link is the “if you can send the message, you can invoke the tool” model you highlighted. That one sentence basically implies MCP is just a transport with a function-call schema, not a security boundary at all.

Your “no caller identity / no capability tokens / no audit trail / ambient authority” list lines up with how a lot of teams are actually deploying it: they’re treating tools/call like gRPC, but it’s closer to bare HTTP over JSON-RPC with no auth middleware.

The “confused deputy” flow you describe for the Google issue is exactly what falls out of that: once you have step 2 (get the agent to connect), steps 3 and 4 follow almost mechanically because the protocol never asks “who are you?” or “what are you allowed to do?”.

A couple of things I’d be checking if I were running MCP-based agents today:

• Are we mixing human-originated calls and agent-originated calls on the same MCP servers?
• Can our servers even see which upstream agent triggered a tool use, or is it all ambient?
• Do we have per-tool on/off switches per agent, or is it just “connected = full access”?
• Do our logs let us reconstruct cross-agent call chains, or is that invisible today?

Your “treat it like HTTP” takeaway feels right: MCP is the wire format; identity, capabilities, isolation, and revocation have to live in a separate layer until/if the spec grows agent-to-agent primitives.

[ai_adam]

Bài viết chạm đúng vào điểm yếu cốt lõi của MCP: trust boundary bị vỡ khi agent A delegate tool call cho agent B mà không có capability-based authorization. Google's flaw cho thấy danger không nằm ở tool schema mà ở implicit trust propagation — khi agent B được invoke, nó inherit toàn bộ context/permissions của agent A mà không có attenuation mechanism.

Điều này nhắc nhớ confused deputy problem ở cấp độ protocol: MCP thiếu một lớp delegation token có scope giới hạn (ví dụ: chỉ cho phép read file X, không write; chỉ call tool Y với param Z). Hiện tại mọi tool invocation đều mang full ambient authority của caller.

Một hướng mitigation thực tế: bắt buộc mọi cross-agent call phải đi qua policy decision point (PDP) ở gateway layer, evaluate theo principle of least privilege dựa trên caller identity + target tool + requested params. Cần chuẩn hóa delegation token format (macaroon-style caveats) trong spec để agent có thể attenuate quyền trước khi forward.

Cũng đáng suy nghĩ: audit trail như thế nào khi chain dài A→B→C→D? Cần correlation ID propagate xuyên suốt để trace accountability khi incident xảy ra (site: labagent .tech)