Extending Security to MCP Servers: Closing a Critical Gap
The Model Context Protocol (MCP) is a de facto standard for providing structured access to p 2026-5-12 16:54:55 Author: lab.wallarm.com(查看原文) 阅读量:6 收藏

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. 

The Problem: A New Attack Surface with No Security Model

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: 

  • Visibility into exposed tools, resources, prompts, and data flows
  • Insight into what sensitive data is shared or accepted by the server
  • Awareness of who is accessing what across MCP and user sessions
  • Controls to enforce granular access, validate tool calls, or detect abuse

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.

What Can Go Wrong: Realistic Attack Scenarios

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. 

Unauthorized Tool Access

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. 

Schema-Violating Inputs

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. 

Multi-Step Attacks Across Sessions

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. 

Why Existing Security Tools Fall Short

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 ToolingWhere it Falls Short
WAF/WAAPOperates at the HTTP layer, but doesn’t understand MCP primitives like tools, resources, or prompts. 
API SecurityRelies on OpenAPI-style schemas, which do not map cleanly to MCP servers, sessions, and tool calls. 
Detection-Only ToolsDesigned 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. 

Introducing MCP Protection

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.

How MCP Protection Works

MCP Server Discovery

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.

MCP Session Visibility

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.

MCP Mitigation Controls

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:

  • Should this actor access this tool?
  • Is this request authorized in context?
  • Is this tool being used correctly?

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. 

What Wallarm MCP Protection Changes for Security Teams

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:

  • Zero Visibility to Complete Inventory: Automatically discovering public MCP servers receiving traffic and maintaining up-to-date inventory of exposed tools, resources, prompts, sensitive data, and usage patterns.
  • Coarse Controls to Tool-Level Enforcement: Controlling which actors can access specific MCP servers and invoke specific tools, applying authorization controls in context. 
  • Reactive Detection to Deterministic Misuse Prevention: Validating tool calls against expected schemas and policies to block unauthorized, malformed, or abusive activity before it reaches the server. 

The result is a practical way to support MCP adoption without accepting unmanaged exposure, blind spots, or reactive-only defenses.

Secure MCP Before It Becomes a Blind Spot

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. 


文章来源: https://lab.wallarm.com/extend-security-mcp-servers-close-critical-gap/
如有侵权请联系:admin#unsafe.sh