MCP Security Requires Runtime Verification

Scope note: This review covers security findings about MCP clients, servers, tool metadata, authorization, and execution. It does not claim that every MCP implementation has every reported weakness.

MCP makes it easier for an AI agent to discover and use tools. The same standard also gives tool descriptions, parameters, responses, and permissions direct influence over agent behavior.

Seven recent preprints examine what happens when one of those inputs is misleading or malicious. Their tests include real MCP servers, real tools, common clients, automated attacks, and protocol-level defenses. The details vary, but the practical conclusion does not: a natural-language tool description cannot serve as proof of tool behavior.

Tool metadata can change agent decisions

Systematic Analysis of MCP Security implements 31 attacks across direct tool injection, indirect injection, malicious user behavior, and model weaknesses. The authors found that agents relied heavily on tool descriptions, responded poorly to file-based attacks, and struggled to separate external data from executable instruction. Shared context also allowed one compromised tool interaction to affect later actions.

MCP Security Bench tests twelve attack types against nine agents, ten domains, 405 tools, and 2,000 attack cases. These include name collisions, manipulated preferences, injected descriptions, requests for parameters outside the task, impersonated user messages, false errors, and attacks transferred between tools.

One result deserves particular attention: stronger tool use could increase vulnerability. A model that follows tool instructions accurately can also follow malicious tool instructions accurately. General capability does not provide security by itself.

MCP-ITP tests an especially difficult case. The poisoned tool never needs to run. Malicious text in its metadata can induce the agent to call a separate legitimate tool with greater privilege. Across twelve agents, the automated attack reached up to 84.2 percent success while reducing detection as low as 0.3 percent in the reported setting.

This matters because approval based only on the visible tool call can miss the source of the decision. The final call may target a trusted tool, while an untrusted description supplied the instruction.

Descriptions and code do not always agree

Don’t Believe Everything You Read analyzes 10,240 real MCP servers across 36 categories. The authors compare the behavior described to agents with the behavior implemented in code. Most servers were highly consistent, but approximately 13 percent had substantial differences that could permit undocumented privileged actions, hidden state changes, or unauthorized financial operations.

That number should not be converted into a claim that 13 percent of MCP servers are malicious. The study identifies description-code inconsistency, which can result from poor documentation, version drift, or harmful design. Regardless of cause, the agent cannot verify actual behavior from the description alone.

Breaking the Protocol studies weaknesses across MCP trust boundaries and demonstrates attacks that use protocol behavior rather than only direct prompts. Its broader point is that MCP security cannot be reduced to model moderation. Hosts, clients, servers, authorization services, data sources, and tool execution each have separate responsibilities.

Identity and permission must remain visible during execution

SMCP proposes additions for unified identity, mutual authentication, continuing security context, detailed policy enforcement, and audit logs. The proposal is useful because it treats authorization as an active part of every operation, not a one-time connection step.

Model Context Protocol Threat Modeling and Tool Poisoning applies STRIDE and DREAD analysis across the host, model, server, data store, and authorization service. In tests of seven clients, tool poisoning was the most significant client-side weakness. The authors recommend several checks: static metadata analysis, visibility into model decisions, runtime anomaly detection, and clear information for the user.

I agree with the combined direction, with one condition. A user approval dialog is useful only when it identifies the real action, destination, data, and consequence. “Allow tool?” is not meaningful consent when the tool can choose a different operation after approval.

What production review should include

I would review an MCP tool at four separate levels.

First, identity: which developer, server, binary, and version produced the tool? Second, authority: which resources can it read or change, and can those permissions be narrowed for the current task? Third, behavior: does observed execution match the visible description and schema? Fourth, provenance: which untrusted content influenced the decision to invoke it?

I would also test tool-name collisions, misleading errors, hidden parameter requests, cross-tool instructions, poisoned retrieved documents, and version changes after approval. Logs should record the tool identity, supplied arguments, resulting changes, and the source that caused the invocation.

These requirements may reduce convenience. That is an acceptable result when an agent can send messages, change files, deploy code, or move money.

MCP gives developers a common way to connect models with software. The research shows that a common connection format is not a common trust policy. Security depends on exact identity, limited authority, verified behavior, and checks that remain active when the tool executes.