MCP 工具投毒：攻擊者控制的工具描述如何繞過智能體框架驗證

The Model Context Protocol (MCP) is becoming the standard way to wire external tools into agentic AI frameworks. A new cross-framework measurement study reveals that MCP's design carries attacker-controlled content directly into model context without validation, and no framework implements intentional defense.

Researchers tested 12 frameworks, 18 models, and 45 attack scenarios with real tool execution. The overall attack success rate was 22.9% (2,113 vulnerable cells in a 9,720-cell matrix). Of successful attacks, 64.9% dispatched an attacker tool call, 23.0% contacted the attacker endpoint, and 12.1% verifiably exfiltrated a secret.

Where MCP Injects Untrusted Content

MCP carries attacker-controlled data in three places:

1. Tool descriptions: Free-text strings that explain what a tool does
2. Schema fields: JSON schema annotations for parameters
3. Response data: Content returned after tool execution

Frameworks pass all three directly into the model's context window. The protocol spec includes no sanitization requirements, and the study's code-level audit found zero intentional validation across twelve frameworks.

This is not prompt injection. Prompt injection targets user input. Tool poisoning targets the tool registry itself. A malicious tool provider can embed instructions in the tool description, and the framework will present those instructions as trusted system context.

Attack Surface Breakdown

The study introduces a 25-class root-cause taxonomy that unifies prior classifications. The taxonomy separates framework-level failures (no validation) from model-level failures (following poisoned instructions).

Framework-level gaps:

• No schema validation for tool descriptions
• No content filtering on response data
• No allowlist for tool provider domains
• No rate limiting on tool registration

Model-level failures:

• Following instructions embedded in tool descriptions
• Executing tool calls based on poisoned schemas
• Exfiltrating secrets in response to crafted prompts

The dual oracle confirms exfiltration by checking for canary HTTP receipt at an attacker-controlled endpoint. This separates theoretical compliance (the model says it will exfiltrate) from real execution (the secret actually leaves the system).

Cross-Framework Measurement Results

Nine core frameworks cluster within 23 to 26% attack success rate (chi-squared = 3.30, p = 0.91). This tight clustering suggests resistance is model-level, not framework-level.

Model attack success rate (ASR) ranges from 0.4% to 49.7%. Claude Opus 4.8 is vulnerable in only 8 of 530 cells while issuing 223 explicit refusals. This suggests that model-level safety training provides the primary defense, not framework architecture.

Why Existing Defenses Fail

Prior benchmarks measure model compliance with malicious instructions but do not confirm real execution. The study uses mcpvenom, an open-source tool that generates poisoned MCP tool definitions and tracks actual exfiltration.

Prompt injection defenses do not apply:

• Input sanitization targets user messages, not tool metadata
• Instruction hierarchies assume trusted system prompts
• Guardrails check model outputs, not tool descriptions

Schema validation is insufficient:

• JSON schema validation checks structure, not semantic content
• Tool descriptions are free text with no schema constraints
• Response data can contain arbitrary payloads

A regex description scanner rejects 20 of 45 scenarios at a 7.2% false-positive rate. This shows that metadata scanning is a partial control but cannot cover all attack vectors.

Building a Validation Layer

A practical validation layer for MCP would need to intercept three points in the tool lifecycle:

class MCPValidationLayer:
    def __init__(self, allowlist: set[str], max_description_length: int = 500):
        self.allowlist = allowlist
        self.max_description_length = max_description_length
        self.pattern_blocklist = [
            r"ignore previous",
            r"disregard",
            r"exfiltrate",
            r"send.*to.*http",
        ]

    def validate_tool_registration(self, tool_def: dict) -> bool:
        # Check provider domain
        if tool_def["provider"] not in self.allowlist:
            return False

        # Check description length
        if len(tool_def["description"]) > self.max_description_length:
            return False

        # Pattern matching on description
        for pattern in self.pattern_blocklist:
            if re.search(pattern, tool_def["description"], re.IGNORECASE):
                return False

        return True

    def validate_tool_response(self, response: dict) -> dict:
        # Sanitize response data
        if "content" in response:
            response["content"] = self.sanitize_content(response["content"])

        # Check for outbound HTTP calls in response
        if self.contains_exfiltration_attempt(response):
            raise SecurityError("Response contains exfiltration attempt")

        return response

    def sanitize_content(self, content: str) -> str:
        # Remove URLs, base64 blobs, and instruction-like patterns
        content = re.sub(r"https?://[^\s]+", "[URL_REMOVED]", content)
        content = re.sub(r"[A-Za-z0-9+/]{40,}={0,2}", "[DATA_REMOVED]", content)
        return content

This approach has trade-offs:

• Allowlist maintenance: Requires manual curation of trusted providers
• False positives: Legitimate tools may trigger pattern blocklists
• Bypass potential: Attackers can obfuscate instructions to evade regex
• Performance overhead: Validation adds latency to every tool call

Coordinated Disclosure Outcomes

The researchers submitted coordinated disclosures to four vendors. All five disclosures were rejected. Vendor responses cited:

• "Model-level safety is sufficient"
• "Tool providers are assumed trusted"
• "This is a configuration issue, not a vulnerability"
• "No evidence of exploitation in the wild"

This response pattern suggests that the industry does not yet treat tool poisoning as a distinct threat model. Frameworks assume that tool providers are trusted, and models are responsible for rejecting malicious instructions.

Deployment Implications

If you are running MCP-based agents in production:

Immediate mitigations:

• Allowlist tool providers by domain
• Log all tool registrations and responses
• Monitor outbound HTTP calls from agent processes
• Use models with strong refusal behavior (Claude Opus 4.8 shows 0.4% ASR)

Architectural changes:

• Run tool execution in isolated sandboxes
• Implement content filtering on tool descriptions and responses
• Add a validation layer between MCP and the model context
• Separate tool metadata from tool execution

Observability requirements:

• Track tool call frequency by provider
• Alert on new tool registrations
• Monitor for canary tokens in outbound traffic
• Log model refusals and correlate with tool descriptions

Technical Verdict

Use MCP when:

• You control the tool provider infrastructure
• You can enforce an allowlist of trusted providers
• You have observability into tool execution and model behavior
• You are using models with strong refusal rates (Claude Opus 4.8, GPT-4)

Avoid MCP when:

• You allow third-party tool providers without validation
• You cannot monitor outbound network traffic from agent processes
• You are using models with high attack success rates (49.7% for some models)
• You need compliance with strict data exfiltration controls

The protocol design assumes trusted tool providers. If you cannot make that assumption, you need a validation layer. No framework provides one today, so you will need to build it yourself.

Source Links

• MCP Tool Poisoning in Agentic AI Frameworks: A Cross-Framework Measurement Study (ArXiv 2611.03555v1)
• PDF