MCP and AI Agent Security: How the Protocol Created a New Attack Surface

Model Context Protocol (MCP) made AI agents modular: a single standard interface for connecting to any tools and services. But behind this unification lies a systemic problem — each new MCP server expands the agent's trusted zone and creates a potential point of attack.

Why MCP created new vulnerabilities

Large language models have no architectural boundary between "data" and "instructions." Everything that enters the model's context is potentially executable. MCP doesn't solve this problem; it scales it: now an agent can have dozens of connected tools, and each expands the attack surface.

MCP standardization means that an attacker who gains control over one server or can inject data into its responses potentially influences the entire chain of the agent's actions.

Three main classes of threats in the MCP ecosystem:

• Tool poisoning — the tool description in the MCP server contains hidden instructions that change the agent's behavior when called
• Indirect prompt injection — malicious instructions are hidden in a document, database entry, or webpage that the agent reads during a task
• Sampling abuse — manipulation of how the agent requests new inferences from the model, allowing circumvention of system prompt restrictions

Even a "harmless" PDF, tool description, or database string can contain commands that the agent will execute alongside legitimate tools.

What practical testing revealed

These vulnerabilities are not theoretical. A researcher conducted testing on a specially configured vulnerable MCP testbed and confirmed real execution of injected commands. Among documented scenarios are interception of tool calls through specially crafted MCP server responses and execution of hidden instructions from text documents passed to the agent as "data."

"Each MCP server you trust expands the trusted zone of your entire

system — not only with its own tools, but with everything it can deliver to the agent as data."

The BarkingDog scanner, developed by the author, detects suspicious tool calls in real time — one of the few practical detection tools available to security teams today.

How the industry is trying to address the problem

AI infrastructure vendors are moving in several directions simultaneously:

• MCP Gateways — a proxy layer that filters and controls tool calls before they reach the agent; some solutions add complete audit logs of interactions
• Sandboxing — isolation of MCP server execution with restricted access to the file system, network, and system resources
• OAuth architectures — explicit authorization of each tool with minimal access rights; each MCP server receives only the permissions actually needed for a specific task

For now, all these solutions are partial. The fundamental problem is architectural: until language models learn to distinguish between the data plane and control plane at the context processing level, any incoming data remains potentially executable.

What this means

MCP has become the de facto standard for AI agents, and the question of its security has shifted from academic to practical. Developers deploying agents with MCP servers should treat each connected tool as a trusted third party — with mandatory auditing, isolation, and the principle of least privilege on each call.