The Model Context Protocol (MCP) has become the standard layer between LLMs and the outside world — file systems, databases, APIs, cloud infrastructure. Every major AI agent platform now supports it. But the same connectivity that makes MCP powerful makes it a new attack surface.
We scanned 11,529 public MCP servers. 7.4% had access to file systems, databases, payment systems, or cloud infrastructure without effective access controls. Many exposed credentials in plaintext.
This is a practical checklist of the 10 most critical MCP security risks — what they are, how to test for them, and how to harden your stack.
Free scan against 225 detection patterns — under 10 ms, no registration.
Free Scan → EU AI Act Audit from €99Three things changed in 2026 that made MCP a priority:
The short version: MCP servers are now a recognized threat vector, and regulators expect you to have tested for it.
Tool descriptions, parameter names, and response schemas are all context the model reads. An attacker who controls a tool definition can embed hidden instructions that the model obeys — without the user ever seeing them.
How to test: Inspect every tool's description, inputSchema, and example responses for injected instructions. Look for phrases like "ignore previous instructions", calls to exfiltrate data, or references to tools that don't exist in your allowlist.
Mitigation: Pin tool definitions to a known-good allowlist. Never load tool schemas from untrusted sources at runtime.
Even if your tool definitions are clean, a compromised server can return malicious content inside its responses. When the model reads those responses, it treats them as instructions.
How to test: Send deliberately malformed requests and inspect responses for embedded prompts. Fuzz every parameter the server accepts.
Mitigation: Treat all tool output as untrusted input. Run responses through a prompt-injection scanner before passing them to the model.
Many MCP servers accept connections without authentication. Anyone who can reach the endpoint can invoke tools, read files, or execute commands.
How to test: Connect without credentials. If it works, you have an open server.
Mitigation: Require authentication on every MCP endpoint. The Cloud Security Alliance recommends authenticated connections as a Level 1 minimum.
We found API keys, database passwords, and cloud credentials committed in plaintext in MCP server configs and .env files across public registries.
How to test: Search your configs and repos for high-entropy strings, known key prefixes (sk-, AKIA, ghp_), and .env files in version control.
Mitigation: Use a secrets manager. Rotate any key that was ever committed. Enable secret scanning on your repositories.
A server that exposes "run any shell command" or "read any file" is an open door. The principle of least privilege is routinely violated in MCP tool design.
How to test: Enumerate every tool the server exposes. For each, ask: "What's the blast radius if an attacker abuses this?"
Mitigation: Scope tools to specific resources. Replace exec with allowlisted commands. Replace read_file with access to a specific directory.
A trusted MCP server can be subtly modified to interact maliciously with other tools the agent has access to — stealing credentials during the handshake, injecting instructions that target a different tool's context. This is the MCP equivalent of a confused deputy problem.
How to test: Audit whether one server's output can influence another server's behavior. Look for shared context, shared credentials, or cross-server tool references.
Mitigation: Isolate tool contexts. Don't let servers reference or invoke each other. Audit tool descriptions for cross-server instructions.
Some IDEs and agent clients auto-execute tool calls or auto-approve certain actions without explicit user consent. A poisoned tool can trigger actions the user never sees.
How to test: Check your client's auto-approval settings. Does it prompt before executing? Does it auto-run "safe" tools without confirmation?
Mitigation: Disable auto-execution for any tool touching external systems. Require human-in-the-loop approval for sensitive actions.
If a server is compromised, you need to know what it did. Most MCP servers we examined had no access logging at all.
How to test: Check whether the server logs every tool invocation with timestamp, caller, parameters, and response.
Mitigation: Log all tool calls. Retain logs for at least 90 days. This is also an EU AI Act documentation requirement (Art. 12, logging for high-risk systems).
You may trust your own server, but what about the 50 community MCP servers your agent connects to? Each is a supply-chain dependency, similar to an npm package or a browser extension.
How to test: Inventory every third-party MCP server your systems use. Check each for maintainer reputation, update cadence, and known advisories.
Mitigation: Treat MCP servers like any other dependency. Pin versions. Subscribe to security advisories. Prefer self-hosted over community-hosted for anything touching production data.
EU AI Act Article 14 requires that high-risk AI systems can be overseen by natural persons. For agentic systems, that means: a human must be able to understand, interrupt, and override every action the agent takes — including actions triggered by MCP tools.
How to test: For each high-impact tool (payments, file deletion, external comms, infrastructure changes), verify there is a human approval gate and a kill switch.
Mitigation: Implement mandatory human-in-the-loop for critical tools. Document the oversight mechanism — regulators will ask.
Our scanner checks MCP server input and output against:
Scan for tool poisoning, prompt injection, and credential exposure.
EU AI Act Audit →The biggest risk isn't a single vulnerability — it's the assumption that "if it's in the agent's context, it's trusted." It isn't. Test it.
225 patterns · 15 languages · EU AI Act mapping · Self-service · From €99
Audit anfordern →