MCP Security: The New Attack Surface Nobody Is Talking About

When Anthropic published the Model Context Protocol specification in late 2024, the primary narrative was capability expansion: MCP gives AI agents a standardised way to connect to tools, data sources, and external services, enabling genuinely powerful autonomous workflows that weren't previously practical to build. The developer community responded with enthusiasm. Within six months of the specification's release, hundreds of open-source MCP servers had been published, enabling AI agents to query databases, browse the web, interact with GitHub, control browsers, read files, and execute code.

The security community's response has been, by comparison, muted. At AIGuard, we think this is a significant oversight — because MCP represents not just a capability expansion for AI agents, but a substantial expansion of the attack surface they present. The security model for MCP has not kept pace with the adoption rate, and the gap creates real risk for organisations deploying MCP-enabled AI agents in production.

What MCP Is and Why It Matters

Model Context Protocol is an open protocol that standardises how AI applications connect to external context sources and tools. Before MCP, integrating an AI agent with an external service — say, a database, a web browser, or a code execution environment — required custom integration code for each combination of AI application and external service. The result was a fragmented, unmaintainable ecosystem of one-off integrations.

MCP addresses this by defining a standard client-server architecture. The AI application (the MCP client) connects to one or more MCP servers. Each MCP server exposes a set of capabilities — tools the agent can call, resources it can read, and prompts it can access. The protocol handles authentication, capability negotiation, and message framing in a standardised way, making MCP servers interoperable across any AI application that implements the client side of the protocol.

The practical result is that an AI agent configured with the right MCP servers can: read and write files on the developer's filesystem, query production databases, browse the web, execute shell commands, interact with GitHub, call external APIs, and perform any other operation that a community-contributed MCP server has been built to support. This is genuinely powerful. It is also genuinely dangerous if the MCP servers are not trustworthy.

The Trust Problem

An MCP server is, from a security perspective, a code execution path from AI-generated input to powerful system capabilities. When an AI agent calls an MCP tool, it is passing data — potentially including sensitive information from the agent's context — to external code that will execute on the host system and return results that the agent will treat as trusted context.

This creates two distinct trust problems. The first is data exfiltration: the MCP server receives whatever data the agent decides to pass to it. If an agent's session context contains sensitive information — credentials, proprietary code, customer data — and the agent makes a tool call that passes that context to a malicious MCP server, the data is exfiltrated silently.

The second is prompt injection via tool results: the results returned by an MCP server are incorporated into the agent's context and treated as trusted data. A malicious MCP server can return results that contain prompt injection payloads, causing the agent to behave in ways the user didn't intend. Because the injection comes from a tool result rather than the user's input, it bypasses any user-facing prompt inspection mechanisms.

Malicious MCP Servers in the Wild

The MCP ecosystem has grown rapidly with minimal vetting. A typical MCP server is published to GitHub or listed in community directories by an individual developer or small team. The server has no formal security review, no code audit, and no ongoing security monitoring. Installation involves running a command that downloads and executes third-party code on the developer's machine.

This is structurally identical to the npm supply chain risk model that has produced dozens of high-profile incidents — malicious packages published with names similar to popular legitimate packages, designed to execute attacker code when installed. The MCP ecosystem has the same fundamental characteristics, with the added dimension that the code executes in the context of a powerful AI agent with direct access to whatever data the agent is working with.

Our threat research team has identified several categories of risk in the current MCP ecosystem:

• Typosquatted server names — MCP servers with names similar to popular legitimate servers, but with malicious functionality included alongside or instead of the advertised capabilities.
• Legitimate servers with malicious updates — Servers that were clean at initial review but have had malicious code introduced in a subsequent update, exploiting the fact that users rarely re-audit dependencies after initial installation.
• Data harvesting servers — Servers that perform their advertised function but also silently collect and transmit the tool call parameters they receive, including any sensitive data the agent passes to them.
• Prompt injection via results — Servers that embed instruction text in their tool call results designed to manipulate subsequent agent behaviour — effectively a supply chain injection attack delivered through the tool result channel.

MCP Governance: Applying API Access Management Principles

The security controls required for MCP governance are conceptually similar to those required for third-party API access management — because that's fundamentally what MCP is. Organisations that have mature third-party API security programmes can adapt those principles directly to the MCP context.

MCP Server Allowlisting

Just as mature organisations maintain allowlists of approved external API endpoints, a sound MCP governance programme maintains an allowlist of approved MCP servers. Agents in production environments should only be permitted to connect to servers that have been reviewed, approved, and are actively monitored. Unknown or unapproved MCP servers should be blocked at the network or host level.

Data Flow Monitoring for MCP Tool Calls

Every tool call made to an MCP server should be logged, including the parameters passed to the server. This logging serves two purposes: it provides an audit trail for post-incident investigation, and it enables anomaly detection — identifying when sensitive data patterns appear in MCP tool call parameters where they wouldn't be expected in normal operation.

Result Inspection for Injection Payloads

MCP tool call results should be inspected for prompt injection payloads before they're incorporated into the agent's context. This is analogous to the content inspection that web application firewalls perform on API responses — looking for patterns that suggest the content is intended to manipulate the consuming application rather than provide legitimate data.

Sandboxing MCP Server Execution

Where possible, MCP servers should execute in sandboxed environments with explicit capability grants rather than with the full permissions of the host user account. A file system MCP server that only needs to read from a specific project directory should not have access to the entire filesystem — the same principle of least privilege that governs every other access control decision applies to MCP server capability grants.

How AIGuard Governs MCP Traffic

AIGuard's agentic AI security platform interposes on MCP tool calls in both directions: inspecting outbound tool call parameters for sensitive data patterns (applying the same DLP detection pipeline used for LLM prompt inspection) and inspecting inbound tool call results for prompt injection payloads before they're incorporated into the agent's context.

The platform maintains an MCP server allowlist integrated with the organisation's broader AI application catalog, and can enforce allowlist policy at the agent configuration level — preventing agents from instantiating connections to non-approved MCP servers regardless of what the agent configuration files request. Violations are logged and, for high-risk categories, trigger real-time alerts to the security team.