The Model Context Protocol (MCP) is a de facto standard for providing structured access to privileged systems for AI agents and external integrations. It acts as a USB-C port for AI, enabling faster innovation by allowing organizations to expose tools, resources, and workflows without the time-consuming work of building APIs.
Adoption has surged in recent months, and categories like payments, project management, and developer platforms are already beginning to reap the benefits. As a result, organizations are participating more deeply in AI ecosystems and developing more dynamic, agent-driven interactions.
But the same flexibility that makes MCP useful also creates a security risk. It drives real business value, but it also introduces a new external attack surface.
As companies begin exposing MCP servers publicly, they are – often unwittingly – creating a new attack surface around capabilities with broad permissions: reading data, invoking actions, and interacting with sensitive internal systems.
The core of the problem is that MCP currently lacks an established security model comparable to OpenAPI. That means security teams lack:
MCP’s stateful, dual-session model compounds the issue.
MCP activity has two layers of identity: the MCP session, which tracks the protocol interaction (typically tracked with the mcp-session-id header), and the authentication user session, which represents the person or system making the request.
Security tools must correlate to understand what actually happened, and traditional API tools weren’t designed to do that. Ultimately, that means you’re exposing powerful capabilities externally, without the controls you rely on for APIs.
MCP servers are exposed without visibility, validation, or access controls, meaning attackers can misuse the same capabilities that make them useful. Here are a few examples.
An attacker discovers a tool intended only for internal admins, such as those for exporting customer data, opening support actions, or modifying account settings.
Because access is not enforced at the tool level, they can invoke privileged functionality that they should not have access to. To existing security tools, the request may appear to be normal traffic to an exposed MCP server rather than unauthorized use of a specific capability.
A tool is designed to accept a narrow set of inputs, but the server does not validate requests against the expected schema.
For example, a customer lookup tool may be designed to accept only a customer ID. Still, the server also accepts unexpected fields such as “include internal notes”, malformed nested options, or oversized payloads. If those inputs reach downstream systems, they can trigger unintended behavior or expose data outside the intended workflow.
An attacker spreads activity across multiple MCP and user sessions.
They start by mapping exposed tools and resources, then test inputs, and then extract sensitive data over time. Because existing tools cannot correlate across both session layers, the behavior appears isolated rather than part of a coordinated attack.
Traditional security tools were designed for REST APIs and web traffic – not MCP. They miss the MCP-specific context necessary to see what’s exposed, who’s using it, and whether each tool call should be allowed.
| Existing Tooling | Where it Falls Short |
| WAF/WAAP | Operates at the HTTP layer, but doesn’t understand MCP primitives like tools, resources, or prompts. |
| API Security | Relies on OpenAPI-style schemas, which do not map cleanly to MCP servers, sessions, and tool calls. |
| Detection-Only Tools | Designed to identify suspicious behavior after the fact, but cannot enforce access, validate requests, or block misuse in real time. |
The bottom line is that existing tools were not built for MCP, leaving critical gaps in visibility and control that attackers can exploit.
Wallarm MCP Protection extends existing discovery, visibility, and mitigation controls to externally exposed MCP servers, bringing MCP into the same operating model security teams already use for APIs.
Wallarm automatically discovers all externally exposed MCP servers and continuously catalogs the tools, resources, prompts, and sensitive data they expose using both traffic analysis and MCP discovery methods, giving security teams a complete, up-to-date inventory without manual effort.
Wallarm provides full visibility into MCP activity by correlating MCP sessions with authenticated user sessions. This enables teams to track behavior across interactions and investigate complex, multi-step attacks in a single, unified view.
For years, OpenAPI has been the foundation of API security. Once you have a spec that defines every endpoint, parameter, and accepted input, you can validate every request against it deterministically, not probabilistically. Calls that don't match the spec get blocked. That's the model security teams already trust for APIs.
MCP has the same building blocks, just under different names. The tools/list, resources/list, and prompts/list responses are, in effect, the published spec for an MCP server: they declare exactly which tools exist, what arguments each one accepts, and what the server is willing to expose.
Wallarm treats those responses as the equivalent of an OpenAPI spec and enforces a positive security model on top of them — granular access control at the tool level, request validation against authorization constraints, and schema-based validation of every tool call.
In practice, that means three questions get answered before a tool call is allowed to reach the server:
If any of them return "no," Wallarm blocks the request before it reaches the MCP server. The validation is deterministic — driven by the schema the server itself published — not pattern-matching or anomaly detection that might miss a novel attack.
Instead of externally exposed MCP servers being an unmanaged blind spot, teams can discover what is exposed, understand how it is used, and enforce controls before abuse reaches the server. That changes the operating model for security teams:
The result is a practical way to support MCP adoption without accepting unmanaged exposure, blind spots, or reactive-only defenses.
MCP adoption is accelerating across industries, and security teams are already being asked to support externally exposed MCP servers in production.
But without purpose-built discovery, visibility, and enforcement, MCP can quickly become a blind spot, exposing powerful capabilities externally without the controls that APIs provide.
Wallarm MCP Protection helps teams get ahead of that risk by bringing MCP servers into a security model they already understand: complete inventory, session-level visibility, granular access control, and real-time prevention.
Get a demo now to see how Wallarm MCP Protection can help you reap the rewards of MCP adoption, without taking on unnecessary risk.