{“lastseen”:”2026-05-12T18:05:09″,”description”:”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. \\n\\nAdoption 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. \\n\\nBut 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. \\n\\n## The Problem: A New Attack Surface with No Security Model\\n\\nAs companies begin exposing MCP servers publicly, they are \u2013 often unwittingly \u2013 creating a new attack surface around capabilities with broad permissions: reading data, invoking actions, and interacting with sensitive internal systems. \\n\\nThe core of the problem is that MCP currently lacks an established security model comparable to OpenAPI. That means security teams lack: \\n\\n * **Visibility** into exposed tools, resources, prompts, and data flows\\n * **Insight** into what sensitive data is shared or accepted by the server\\n * **Awareness** of who is accessing what across MCP and user sessions\\n * **Controls** to enforce granular access, validate tool calls, or detect abuse\\n\\n\\n\\nMCP\u2019s stateful, dual-session model compounds the issue. \\n\\nMCP 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. \\n\\nSecurity tools must correlate to understand what actually happened, and traditional API tools weren\u2019t designed to do that. Ultimately, that means you\u2019re exposing powerful capabilities externally, without the controls you rely on for APIs.\\n\\n## What Can Go Wrong: Realistic Attack Scenarios\\n\\nMCP 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. \\n\\n### Unauthorized Tool Access\\n\\nAn attacker discovers a tool intended only for internal admins, such as those for exporting customer data, opening support actions, or modifying account settings. \\n\\nBecause 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. \\n\\n### Schema-Violating Inputs\\n\\nA tool is designed to accept a narrow set of inputs, but the server does not validate requests against the expected schema. \\n\\nFor example, a customer lookup tool may be designed to accept only a customer ID. Still, the server also accepts unexpected fields such as \u201cinclude internal notes\u201d, malformed nested options, or oversized payloads. If those inputs reach downstream systems, they can trigger unintended behavior or expose data outside the intended workflow. \\n\\n### Multi-Step Attacks Across Sessions\\n\\nAn attacker spreads activity across multiple MCP and user sessions. \\n\\nThey 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. \\n\\n## Why Existing Security Tools Fall Short\\n\\nTraditional security tools were designed for REST APIs and web traffic \u2013 not MCP. They miss the MCP-specific context necessary to see what\u2019s exposed, who\u2019s using it, and whether each tool call should be allowed. \\n\\n**Existing Tooling**| **Where it Falls Short** \\n—|— \\n**WAF\/WAAP**| Operates at the HTTP layer, but doesn\u2019t understand MCP primitives like tools, resources, or prompts. \\n**API Security**| Relies on OpenAPI-style schemas, which do not map cleanly to MCP servers, sessions, and tool calls. \\n**Detection-Only Tools**| Designed to identify suspicious behavior after the fact, but cannot enforce access, validate requests, or block misuse in real time. \\n \\nThe bottom line is that existing tools were not built for MCP, leaving critical gaps in visibility and control that attackers can exploit. \\n\\n## Introducing MCP Protection\\n\\nWallarm 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.\\n\\n## How MCP Protection Works\\n\\n### MCP Server Discovery\\n\\nWallarm 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.\\n\\n### MCP Session Visibility\\n\\nWallarm 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.\\n\\n### MCP Mitigation Controls\\n\\nFor 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.\\n\\nMCP 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. \\n\\nWallarm treats those responses as the equivalent of an OpenAPI spec and enforces a positive security model on top of them \u2014 granular access control at the tool level, request validation against authorization constraints, and schema-based validation of every tool call.\\n\\nIn practice, that means three questions get answered before a tool call is allowed to reach the server:\\n\\n * Should this actor access this tool?\\n * Is this request authorized in context?\\n * Is this tool being used correctly?\\n\\n\\n\\nIf any of them return \\”no,\\” Wallarm blocks the request before it reaches the MCP server. The validation is deterministic \u2014 driven by the schema the server itself published \u2014 not pattern-matching or anomaly detection that might miss a novel attack. \\n\\n## What Wallarm MCP Protection Changes for Security Teams\\n\\nInstead 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:\\n\\n * **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.\\n * **Coarse Controls to Tool-Level Enforcement:** Controlling which actors can access specific MCP servers and invoke specific tools, applying authorization controls in context. \\n * **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. \\n\\n\\n\\nThe result is a practical way to support MCP adoption without accepting unmanaged exposure, blind spots, or reactive-only defenses.\\n\\n## Secure MCP Before It Becomes a Blind Spot\\n\\nMCP adoption is accelerating across industries, and security teams are already being asked to support externally exposed MCP servers in production.\\n\\nBut without purpose-built discovery, visibility, and enforcement, MCP can quickly become a blind spot, exposing powerful capabilities externally without the controls that APIs provide. \\n\\nWallarm 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. \\n\\nGet a demo now to see how Wallarm MCP Protection can help you reap the rewards of MCP adoption, without taking on unnecessary risk. \\n\\nThe post Extending Security to MCP Servers: Closing a Critical Gap appeared first on Wallarm.”,”published”:”2026-05-12T16:54:55″,”modified”:”2026-05-12T16:54:55″,”type”:”wallarmlab”,”title”:”Extending Security to MCP Servers: Closing a Critical Gap”,”source”:””,”references”:””,”id”:”WALLARMLAB:044F5C7FA505278EB43086DCBDA2301C”,”bulletinFamily”:”blog”,”cwe”:null,”cvelist”:[],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:0,”severity”:”NONE”,”vector”:”NONE”,”version”:”NONE”},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/lab.wallarm.com\/extend-security-mcp-servers-close-critical-gap\/”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2026-05-12T18:05:09″,”description”:”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…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,12,13,33,7,11,5,105],"class_list":["post-53686","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-exploit","tag-news","tag-none","tag-security","tag-tapic","tag-vulnerability","tag-wallarmlab"],"yoast_head":"\n