5 minutes
MCP Security: The Complete Guide to Securing MCP Servers
Linda Vu Nguyen
MCP security is the practice of evaluating, hardening, and governing Model Context Protocol servers: the middleware that connects AI agents to the tools, data sources, and external systems those agents act on. Because MCP servers translate agent intent into real operations, a single vulnerability in an MCP server can expose credentials, internal infrastructure, or sensitive data to any agent that connects to it, or to any attacker who can manipulate one.
As of June 2026, BlueRock has scanned more than 12,000 public MCP servers through the MCP Trust Registry (N=12,000+). What we found: 6% have critical vulnerabilities. Roughly one in three have SSRF flaws that could expose internal infrastructure. These are not theoretical risks. They are gaps that exist right now in servers your agents may already be connecting to.
This guide maps the full MCP attack surface, explains the most consequential threat classes, and points to the concrete steps for securing your MCP deployments. Links to detailed how-to guides appear throughout.
Why MCP is a new attack surface
The Model Context Protocol standardizes how AI agents communicate with external tools and data systems. An MCP server sits between the agent and the system the agent acts on: it receives tool call requests from the agent, executes them against real infrastructure, and returns results.
That position in the architecture makes MCP servers uniquely consequential from a security standpoint. Traditional API security treats endpoints as passive targets. MCP servers are different: they are execution intermediaries invoked dynamically by agents that make decisions at the app runtime. An agent doesn't call a fixed endpoint on a deterministic path. It selects tools, constructs parameters, and chains operations based on context that changes with every run.
Three factors compound the exposure:
Volume and velocity. More than 20,000 new MCP servers are published every month. The ecosystem is expanding faster than security review practices can keep up, and many of those servers are built by developers optimizing for functionality, not security.
Implicit trust. When a developer connects an MCP server to an agent, they grant that server the ability to act on the agent's behalf. If the server has a vulnerability, or if the server itself is malicious, that implicit trust becomes the attack path.
The agentic execution path. An AI agent operating through MCP servers doesn't just call one tool. It chains actions: read a file, query a database, write results, spawn a subprocess. Each step crosses what BlueRock calls the Agentic Action Path, and each step is an opportunity for a vulnerable MCP server to redirect the agent's actions toward unintended outcomes.
What the data shows: BlueRock scan results
BlueRock's MCP Trust Registry has scanned more than 12,000 public MCP servers as of June 2026. The findings show systemic gaps, not edge cases.
Finding | Rate | What it means |
|---|---|---|
Critical vulnerabilities | 6% | About 1 in 16 public servers has at least one critical flaw |
Unbounded URI fetch / SSRF | 33% | Server can be used to reach internal infrastructure or cloud metadata APIs |
Command injection | 42% | Server executes attacker-controlled input as shell commands or subprocesses |
These vulnerabilities exist across servers with active user bases, not just abandoned projects. When an MCP server has an SSRF flaw, a compromised or manipulated agent can use it to reach cloud instance metadata services, internal APIs, and credential stores: infrastructure the agent was never intended to touch.
BlueRock runs 22 security rules across every scanned server, mapped to the OWASP MCP Top 10, MAESTRO, and MITRE CWE frameworks. Each finding includes code-level evidence down to the specific line, with remediation guidance. The goal isn't a score: it's actionable findings a developer can act on before an agent connects.
The MCP threat classes
Six threat classes account for most of the risk surface in MCP deployments.
1. Unrestricted network fetch and SSRF. Server-Side Request Forgery in an MCP server means the agent can direct the server to fetch arbitrary URLs, including cloud instance metadata endpoints that return credentials and internal configuration. The server acts as a proxy to infrastructure it was never meant to reach. It's prevalent because developers building MCP servers with HTTP fetch functionality often don't scope the allowed URL space.
2. Command injection. An MCP server that passes agent-supplied parameters directly to shell commands or subprocess calls is vulnerable to command injection. An agent executing a task like "run this script" can, if the server doesn't sanitize input, inject arbitrary shell commands that execute with the server's permissions. MCP servers are often thin wrappers around existing CLI tools, and parameterizing those wrappers without input validation is a common shortcut.
3. Authentication and authorization gaps. Not all MCP servers enforce authentication on inbound connections, and many that do don't scope what an authenticated agent can do. A server without fine-grained authorization lets any connected agent exercise the server's full capability set. BlueRock's tool classification model assigns each MCP tool a classification (read, write, destructive, admin, iam, or cost-impact) so governance policies can be scoped to what the tool actually does, not just whether the agent is authenticated.
4. Denial of wallet and cost controls. Agents can exhaust API quotas, compute budgets, or billing limits through unbounded or recursive tool calls. An MCP server with no rate limiting or cost controls allows an agent, or an attacker who has manipulated one, to trigger repeated expensive operations. This is the threat class BlueRock calls "denial of wallet": not a data breach, but a financial and availability attack.
5. Dependency and supply chain risk. MCP servers depend on packages from public registries. A compromised or maliciously named package, a dependency with a known CWE, or a transitive dependency with an undisclosed flaw can introduce vulnerabilities into an otherwise correctly implemented server. BlueRock's scan includes dependency chain analysis as part of the 22-rule set.
6. Path traversal. MCP servers that handle file paths based on agent input can be manipulated to read or write files outside their intended scope. A path traversal vulnerability turns a file-handling MCP tool into unauthorized access to configuration files, credentials, or application code.
The threat matrix
Map each threat class to how it's exploited, the OWASP MCP Top 10 category, and BlueRock's scan coverage. Use it for internal security reviews or to frame conversations with security teams evaluating MCP deployments.
Threat class | How it's exploited | OWASP MCP category | BlueRock scan coverage |
|---|---|---|---|
Unbounded URI fetch / SSRF | Agent directs server to fetch internal URLs or cloud metadata | Improper input handling | Yes, 22-rule scan, code-level evidence |
Command injection | Agent-supplied params passed unsanitized to shell/subprocess | Injection flaws | Yes |
Auth / authorization gaps | No authentication, or no per-tool authorization scoping | Broken access control | Yes |
Denial of wallet / cost controls | Unbounded recursive or expensive calls with no rate limit | Resource exhaustion | Yes |
Dependency supply chain | Compromised or malicious transitive dependency | Supply chain risks | Yes |
Path traversal | Agent-controlled path input escapes intended directory | Path traversal | Yes |
MCP security across the Agentic Action Path
The six threat classes describe vulnerabilities at the MCP server level. But in production, MCP servers don't operate in isolation. They sit inside a chain from the model to the outcome: model → agent → MCP → data → execution → outcome.
That chain is the Agentic Action Path. MCP security understood at the path level means more than scanning servers before you connect them. It means knowing what the agent actually did at each step.
Consider a realistic chain: the agent receives a task and selects three MCP tools; tool one reads a configuration file; tool two queries a database based on what it found; tool three writes a result to an external API. A gateway sees three tool call requests: "read_config," "query_db," "write_api." It does not see the query parameters, the data accessed, or the API payload. If any operation exceeded the agent's intended scope, the gateway has no way to know.
BlueRock maps the full chain:
That's the difference between MCP security as pre-deployment scanning and MCP security as runtime governance. Both matter. The scan tells you what vulnerabilities exist before an agent connects. The runtime layer tells you what the agent actually did once it did.
For why gateway-level inspection is structurally insufficient, see why gateways can't secure agentic AI and the technical limitations of MCP gateways for agentic AI. For the full execution gap this creates, see what is the Agentic Execution Gap?
The shadow MCP problem
MCP security is complicated by a deployment reality: security teams often don't know which MCP servers developers have connected. Developers integrating agents through tools like Cursor, Claude Code, or Windsurf can configure MCP servers locally or through project configuration files, bypassing central security review. Security teams relying on gateway-level visibility see traffic from servers they didn't approve, to tools they didn't evaluate, executing actions they didn't sanction.
This is the shadow MCP problem: an organizational and visibility problem, not just a code-level one. The detection and governance approach is covered in how to detect shadow MCP servers.
How to secure MCP servers: the approach
Effective MCP security operates across three stages: before the agent connects, while the agent runs, and across the full deployment.
Before connecting: scan and classify. Evaluate every MCP server against a structured rule set before connecting agents to it. The MCP Trust Registry provides scan results for 12,000+ public servers; for internal or enterprise builds, private repo scanning applies the same 22-rule analysis to your own repositories. Classify each tool the server exposes (read, write, destructive, admin, iam, or cost-impact): classification-aware policies are more precise than blanket allow/block rules.
During execution: runtime guardrails. Static scanning identifies vulnerabilities in server code. It does not govern how agents use correctly implemented servers. Runtime guardrails sit inside the execution path and enforce policies before the agent's action completes: blocking SSRF attempts at the MCP layer, preventing privilege escalation via expansive tool arguments, and enforcing cost controls. BlueRock Guardrails add less than 5ms of enforcement latency.
Across the deployment: observability. Knowing what agents actually did in production is the foundation for continuous improvement and incident response. How to choose the right MCP server covers evaluation criteria that make this easier at selection time.
For step-by-step implementation: how to secure MCP servers (hardening checklist) and MCP security best practices (ongoing operational patterns).
How BlueRock helps
BlueRock addresses MCP security across the full lifecycle: scan before you connect, govern while agents run.
MCP Trust Registry scans MCP servers against 22 security rules mapped to OWASP MCP Top 10, MAESTRO, and MITRE CWE. Results include code-level evidence down to the line, tool classification (read/write/destructive/admin/iam/cost-impact), and remediation guidance. Public servers are searchable at mcp-trust.com; private repo scanning is available for internal and enterprise builds.
Guardrails provide runtime enforcement across the Agentic Action Path: blocking SSRF at the MCP layer, preventing privilege escalation via expansive tool arguments, enforcing cost controls, and protecting against credential harvesting, CLI-wrapper exploits, and remote code execution. Enforcement adds less than 5ms of latency overhead.
Both are powered by the Trust Context Engine, which enriches execution with identity, trust attributes, and operational signals across agents, tools, MCP servers, and infrastructure. That context is what makes enforcement precise rather than blunt.
"Security is the #1 impediment to agentic adoption," Anthropic has noted. MCP security is where that impediment is most concrete. The 6% critical vulnerability rate across public MCP servers is not a problem that awareness alone solves; it requires tooling that sits in the path.
Start here
Check any public MCP server at mcp-trust.com. Private repo scanning is available for your internal MCP builds.
Explore the MCP Security cluster:
How to secure MCP servers — step-by-step hardening guide
MCP security best practices — operational patterns for ongoing governance
How to detect shadow MCP servers — finding MCP servers your security team didn't approve
FAQ
What is MCP security?
MCP security is the practice of evaluating, hardening, and governing Model Context Protocol servers — the middleware that connects AI agents to tools, data sources, and external systems. Because MCP servers execute agent-requested actions against real infrastructure, a vulnerability in an MCP server can give an agent (or an attacker manipulating one) access to unintended systems, credentials, or data. MCP security covers code-level scanning, tool classification, runtime guardrails, and supply chain review.
How common are vulnerabilities in MCP servers?
Based on BlueRock's scan of 12,000+ public MCP servers (as of June 2026), 6% have critical vulnerabilities. The most prevalent issue is unbounded URI fetch / SSRF, found in 33% of servers, meaning roughly one in three public MCP servers could be leveraged to reach internal infrastructure. Command injection flaws appear in 42% of scanned servers.
What are the most common MCP security vulnerabilities?
The most common MCP security vulnerabilities are unbounded URI fetch and SSRF (33% of servers), command injection via process execution (42%), authentication gaps, path-traversal vectors, transport layer security failures, and dependency supply chain risks. These map to the OWASP MCP Top 10, MAESTRO, and MITRE CWE frameworks. BlueRock's 22-rule scan surfaces all of them with code-level evidence down to the line.
How do I scan an MCP server for security vulnerabilities?
BlueRock's MCP Trust Registry scans MCP servers against 22 security rules mapped to OWASP MCP Top 10, MAESTRO, and MITRE CWE, returning code-level findings down to the line, each with remediation guidance. Public servers can be checked at mcp-trust.com. Organizations with internal or enterprise MCP deployments can use private repo scanning to apply the same analysis to their own builds before connecting agents.
What is the difference between MCP security and gateway security?
Gateways inspect tool call requests at the boundary: they see "tool_call: database_query" but not the actual query or what the agent does with the result. MCP security goes deeper, covering the server's code (what it allows an agent to do), the runtime execution path (what the agent actually did), and the resulting data flows. Gateways are necessary but insufficient; MCP security covers the full execution context.
