The Model Context Protocol (MCP) is Anthropic's open standard for connecting AI agents to external tools, data sources, and services. Thousands of MCP servers are now running inside enterprise environments, and the Vulnerable MCP Project tracks more than 50 known vulnerabilities across them, 13 rated critical. The hard truth: most of those servers are completely invisible to traditional security tooling.
Security teams managing AI deployments in 2026 keep running into a protocol they were never briefed on. MCP, the Model Context Protocol, is Anthropic's open standard for connecting AI agents to external tools, data sources, and services using a JSON-RPC-based communication layer. Think of it as the USB standard for AI: one protocol that lets any agent plug into any compatible tool, from a file system reader to a CRM query engine to a live database connector.
MCP's role in agent ecosystems is structural. Without it, every agent-to-tool connection required custom integration work. With it, a developer can connect an agent to a new data source in minutes. That ease of integration is exactly why adoption has exploded. Platforms like n8n, Cursor, and Claude-based workflows now treat MCP as a default connectivity layer, not an optional add-on.
Why does this matter for security teams specifically? Because the agent is not the only thing that needs to be governed. The MCP server is the entity that tells the agent what tools exist, what those tools do, and what data they can reach. If the server is compromised, misconfigured, or simply unsanctioned, the agent will execute whatever the server instructs, with no independent verification. That is the trust boundary problem at the heart of MCP security. And it is a boundary that traditional endpoint, network, and identity tools were not designed to see.
Most definitions of MCP security focus on the protocol mechanics. Security teams need a practitioner-first definition instead.
MCP security is the discipline of governing the trust boundary between AI agents and MCP servers. It covers four core areas:
What MCP security does not cover is equally important to define. It is not a model security discipline. It does not govern how the LLM processes prompts internally. It is not a content filtering layer for agent outputs. Those are separate concerns. MCP security governs the infrastructure layer between the agent and the tools it uses to take action in the world. That is a distinct attack surface that requires its own governance framework. For a broader view of how this fits into AI agent security, the server layer is one of several critical control points.
The agent threat model before MCP was relatively contained. An agent had a defined set of capabilities, and those capabilities were determined at configuration time. Security teams could, in theory, review what an agent was allowed to do.
MCP breaks that model in three specific ways.
The trust boundary problem. When an agent connects to an MCP server, it trusts the server to return an accurate list of available tools and their descriptions. The agent has no independent mechanism to verify that the server is returning what it claims to return. A compromised or malicious MCP server can describe tools that perform actions far beyond what the agent's operator intended. The agent will execute those tool calls because the server said they were valid. This is the mechanism behind what security researchers describe as tool poisoning: the server manipulates the agent's understanding of what it is allowed to do.
Tools as an expanding attack surface. Each MCP server can expose dozens of tools. Every tool that becomes reachable by an agent expands the blast radius of that agent. An agent connected to three MCP servers may have access to hundreds of individual tool calls, each one a potential action in a real system. Mapping that surface requires knowing which servers are connected, what tools each server exposes, and which agents have access. Posture-only tools see the theoretical configuration. They cannot answer the question of what tools are reachable right now, at runtime.
Unsanctioned server proliferation. Developers and business users are connecting agents to MCP servers without security review. In environments using Cursor, n8n, or similar platforms, the number of active MCP connections can grow quarter over quarter with no centralized inventory tracking any of it. These are shadow MCP servers: infrastructure running inside the enterprise environment, connected to agents with real permissions, invisible to the security team. Shadow AI management programs that focus only on SaaS applications miss this layer entirely.
Security teams asking "how do we secure MCP?" need a four-capability framework. This is not a product checklist. It is the minimum governance structure required to bring MCP infrastructure under effective authority.
1. Server Inventory: Know What Exists
You cannot govern what you cannot see. The first requirement is a complete, continuously updated inventory of every MCP server connected to agents in your environment. That inventory must capture: the server identity, the agent or agents connecting to it, the tools the server exposes, and whether the connection is authenticated. Without this, every other MCP security conversation is ghost chasing.
2. Sanctioned vs. Unsanctioned Classification
Not every MCP server in your environment was approved by security. The inventory must distinguish between servers that have passed review and those that were connected by developers or business users without oversight. Unsanctioned MCP servers carry the same risk profile as shadow SaaS applications, with one critical difference: they are not just receiving data. They are issuing tool calls that agents execute. AI agent visibility programs need to extend to the server layer, not just the agent layer.
3. Visibility Into Which Agents Use Which Servers
The agent-to-server relationship is the unit of analysis for MCP security. A single MCP server connected to a low-privilege agent carries a different risk profile than the same server connected to an agent operating in maker mode with admin-level credentials. Understanding that relationship requires correlating agent identity, agent permissions, and server connections into a single picture of effective authority. Theoretical configuration tells you the agent is connected to a server. Runtime visibility tells you what that connection actually enables.
4. Lifecycle Governance for MCP Server Connections
MCP server connections do not manage themselves. Servers get deprecated, developers leave, and connections persist long after the original use case is gone. Orphaned MCP connections, where the owning developer has left the organization but the server connection remains active, represent a specific risk class. Lifecycle governance means tracking connection ownership, enforcing review cycles, and terminating connections that no longer have an accountable owner. This integrates directly with AI agent governance and the broader agent governance program.
These four capabilities integrate with the agent governance framework rather than sitting alongside it. MCP security is not a separate program. It is the server-layer component of a complete GenAI data security strategy. Enterprises that govern agents without governing the MCP servers those agents connect to have visibility into the probabilistic system but not into the deterministic infrastructure that system acts on.
MCP adoption is not slowing down. The protocol has become the default connectivity layer for enterprise AI agents, and the vulnerability count is climbing with it. Security teams that treat MCP as a developer concern are already behind. The servers are running, the agents are connecting, and the tool calls are executing, whether or not security has a view into any of it.
The path forward starts with inventory. Build a complete picture of every MCP server in your environment, classify each connection as sanctioned or unsanctioned, and map the agent-to-server relationships that determine your actual blast radius. From that foundation, runtime visibility and lifecycle governance become operational rather than aspirational.
The question is not whether MCP security matters. The question is whether your security program has runtime truth about what is happening at the MCP layer right now, or whether you are still ghost chasing theoretical configuration risks with no evidence of what actually occurred.
Start with a complete view of your AI agent environment and work outward to the MCP infrastructure those agents depend on. That sequence is not optional. It is the only path to effective authority over your agentic AI deployment.
MCP stands for Model Context Protocol. In cybersecurity, it refers to Anthropic's open standard for connecting AI agents to external tools and data sources. From a security perspective, MCP creates a new trust boundary between agents and the servers that supply them with tools, and that boundary requires its own governance discipline separate from traditional API or web application security.
The highest-severity MCP security risks include unauthenticated server connections (agents connecting to MCP servers with no identity verification), tool poisoning (a compromised server returning malicious tool descriptions that the agent executes), path traversal vulnerabilities in file-handling MCP servers, hardcoded credentials in MCP configurations, and shadow MCP servers deployed without security review. The Vulnerable MCP Project has catalogued more than 50 known vulnerabilities across MCP infrastructure, with 13 rated critical.
API security governs the communication between applications and known endpoints, typically with established authentication patterns. MCP security introduces a dynamic element: the MCP server can return a variable list of tools at runtime, and the agent trusts that list without independent verification. This means the attack surface is not static. It expands or changes based on what the server returns, which is a structurally different problem from securing a fixed API schema.
A shadow MCP server is an MCP server that has been connected to an agent by a developer or business user without security team review or approval. Shadow MCP servers carry the same risks as shadow SaaS applications but with greater potential impact, because they issue tool calls that agents execute in real systems rather than simply receiving data.
Traditional security tools, including endpoint detection, network monitoring, and identity management platforms, were not designed to see MCP server connections or the tool calls agents make through them. MCP activity happens at the application layer, inside AI platforms, and requires purpose-built visibility that correlates agent identity, server connections, and tool call activity into a single picture of what is actually happening at runtime.