MCP Server Security: Why Your Vulnerability Scanners Can't See Your AI Agents
MCP server security means securing the Model Context Protocol servers that connect AI agents to your tools and data. That means authenticating every server, scoping its tool access, monitoring its sessions, and keeping it in your asset inventory. Most environments skip all four, which is how one misconfigured server becomes a path to full host compromise.
In an AI agent deployment we recently reviewed, the team had connected a handful of MCP servers so their assistant could query internal systems and run maintenance tasks. The servers worked, so nobody looked at them again. When we asked for the list, it took days to assemble. Most were community-built, pulled from a public registry, and none appeared in the asset inventory. That silence is the real MCP server security problem.
The Model Context Protocol became the default wiring for agentic AI, and the ecosystem has passed 150 million package downloads [1]. Adoption is real. So is the exposure. On September 2, 2026, CISA added CVE-2026-59822 to its Known Exploited Vulnerabilities catalog, a CVSS 8.8 flaw in LiteLLM's MCP endpoint that lets an unauthenticated attacker establish a fully authenticated session [3]. On September 15, NIST finalized IR 8587, guidance on protecting exactly the kind of tokens these systems use [2]. The standards bodies are moving. Most environments still cannot tell you which MCP servers they run.
Why Don't Vulnerability Scanners See MCP Servers?
Because most MCP servers are not network services in the way your scanning program expects, and most are not in the asset inventory that scopes the scan. If the scanner does not know a server exists, it will never scan it.
There are two transports, and both create a blind spot. The STDIO transport runs the server as a local process on a workstation, a build server, or a container, launched by the client that uses it. It has no network exposure at all, so a network scan finds nothing. The Streamable HTTP transport listens on a network socket, but in practice it is usually bound to localhost or an internal address, on a host that was never added to the scan scope.
The result is a coverage gap that looks like a scope problem, not a scanner problem. A July 2025 internet scan identified at least 1,862 publicly accessible MCP instances responding to unauthenticated requests [1]. Those were the exposed servers, the ones anyone could find. The far larger population sits on internal hosts that no scanner was ever pointed at, and the risk in that population is arguably worse, because no one is watching it.
What Are the Documented MCP Server Risks?
The documented risks fall into two groups: flaws in the servers and their SDKs, and design defaults in the protocol itself that treat untrusted input as trusted.
The STDIO design flaw. OX Security's April 2026 research found that the official MCP SDKs for Python, TypeScript, Java, and Rust pass configuration parameters directly to the host shell without sanitization or validation [1]. Any process command in an MCP configuration executes on the host. The research estimated 200,000 vulnerable instances across a supply chain with more than 150 million downloads, catalogued four exploitation families, and produced over thirty responsible disclosures [1].
Authentication is optional. The MCP authorization specification defines an OAuth 2.1 framework but explicitly marks authorization optional [1]. The default is no authentication. Anthropic has confirmed the behavior is intentional and declined to change the protocol architecture, leaving sanitization and authentication to downstream developers [1].
The CVE cascade is real. As of May 2026, at least seven confirmed high- or critical-severity CVEs span major MCP-integrated platforms, including MCP Inspector, LiteLLM, Cursor IDE, LibreChat, and Windsurf [1]. Then in September 2026, an actively exploited MCP flaw, CVE-2026-59822, landed on CISA's KEV catalog under a three-to-seven-day remediation window set by BOD 26-04 [3]. It was the second LiteLLM MCP flaw in three months. The first, CVE-2026-42271, had been added to KEV in June [3].
The protocol-level attacks. Even a patched server is exposed to attacks a scanner cannot model: prompt injection carried in tool descriptions the model reads but the user never sees, and cross-server tool shadowing, where one malicious server hijacks the tool names of a trusted neighbor [1].
How Do You Bring MCP Servers Under Existing Controls?
You treat every MCP server as an untrusted third-party service: give it an identity, scope its access, feed it into scanning and monitoring, and manage its updates like any other component. The Cloud Security Alliance's own guidance lands on the same point: treat every MCP server as untrusted, apply zero trust controls at the tool integration layer, and run ongoing governance rather than a one-time patch cycle [1].
Inventory before anything else. List every MCP server, its transport, its source, and the agents that use it. Workstations and build servers that host STDIO processes belong in the scan scope. Without the list, every other control is a guess.
Identity and token hygiene. NIST IR 8587, finalized on September 15, 2026, recommends short-lived, scoped tokens instead of long-lived static credentials, with attention to signing key protection, token verification, and lifecycle controls [2]. Apply that to every MCP client and server. A bearer token that opens a fully authenticated session is precisely the weakness CVE-2026-59822 exploited [3].
Segment and sandbox. STDIO servers should run in isolated containers or dedicated hosts, with no direct access to production credentials and no broad network reach. If a server executes shell commands, the blast radius of its compromise is the blast radius of the host.
Monitor the sessions. Log every MCP session, every tool call, and every configuration change, and alert on the anomalies. A managed SOC can ingest these logs and watch for the patterns that matter, like a new tool appearing or a token used from an unfamiliar host (managed SOC service).
Govern the supply chain. Pin server versions, verify provenance, review every update, and track advisories and KEV entries for the components you run.
Test your own environment. Answer these three questions for your AI agent stack:
- Can you list every MCP server you run, where it runs, and which agent uses it?
- Which of them require authentication?
- Which of them can execute shell commands on the host?
If you cannot answer all three quickly, the next step is a scoped review. Clone Systems can inventory your MCP servers, assess their exposure, and build the remediation plan as part of an AI security assessment or a managed security engagement (schedule a demo).
The Clone Systems MCP Server Security Baseline
This is the 10-point baseline we use when we review an AI agent deployment. Run it against your own environment before you book anyone.
- Inventory. Every MCP server, its transport (STDIO or Streamable HTTP), its source (first-party, vendor, community registry), and the agents that use it.
- Authentication. No MCP server without authentication, including local STDIO servers reachable through a client.
- Authorization. Least-privilege, scoped tool access. No broad-privilege service accounts.
- Token hygiene. Short-lived, scoped tokens only. No long-lived static API keys in MCP configurations [2].
- Input validation. Every tool parameter treated as untrusted input: file paths, commands, URLs, and query strings.
- Supply chain. Pinned versions, verified checksums, reviewed update notes, and a rug-pull watch on registry sources.
- Segmentation. Servers on isolated hosts or containers, with no direct access to production credentials or internal networks.
- Monitoring. Sessions, tool calls, and configuration changes logged, with alerts on anomalies.
- Patch management. A defined process and deadline for KEV-tracked and advisory-tracked MCP vulnerabilities.
- Review cadence. Re-validate the inventory and the controls at every new server onboarding and at least quarterly.
A team that can produce a clean answer to all ten is in good shape. A team that cannot usually has a gap in the first three, and that is where the exposure is.
How Clone Systems Can Help
MCP server security is not a one-time task. It is a standing control for a surface that changes every time an engineer adds a new tool. That is where a managed program beats a project.
We run AI security assessments that inventory your MCP servers, test their exposure, and map the gaps to the baseline above. For the workstations and build servers that host STDIO processes, agent-based scanning closes the blind spot that network scanning cannot reach. For the monitoring side, our managed SOC watches the sessions and tool calls you now have no visibility into. And CloneGuard AI is built to keep your agent deployments honest as they change.
If your agents are talking to tools today, the question is not whether they will be attacked. It is whether you will know about it. Start with an assessment, and you will at least know what you are defending (contact us).
Frequently Asked Questions
What is MCP server security? MCP server security is the practice of securing the Model Context Protocol servers that connect AI agents to tools, databases, and APIs. It covers authentication, tool scoping, input validation, monitoring, and supply-chain management for every server an agent can reach.
How do you secure an MCP server? Run it behind real authentication with least-privilege, short-lived tokens, treat every tool parameter as untrusted input, and log every session and tool call. Also pin the server version, verify its provenance, and add it to your asset inventory so it gets scanned and patched like any other service.
Do MCP servers require authentication? No, the MCP authorization specification defines OAuth 2.1 but marks authorization optional, and many deployments ship without it. A July 2025 internet scan found at least 1,862 publicly accessible MCP instances responding to unauthenticated requests, which is why every server should be authenticated by default.
Can a vulnerability scanner find MCP servers? Usually not, because most MCP servers are local STDIO processes or localhost HTTP services that never make it into the asset inventory that scopes the scan. You need an explicit AI infrastructure inventory before a scanner has anything to scan.
What happened with CVE-2026-59822? CISA added this LiteLLM flaw to its Known Exploited Vulnerabilities catalog on September 2, 2026. It scored CVSS 8.8 and let an unauthenticated attacker establish a fully authenticated MCP session using an arbitrary bearer token.
Does NIST guidance cover MCP? NIST IR 8587, finalized in September 2026, covers the identity tokens and assertions that MCP-based systems use, rather than the MCP protocol itself. Its core recommendation, short-lived scoped tokens instead of long-lived static credentials, applies directly to any AI agent stack.
Conclusion
The MCP servers your agents depend on are already part of your attack surface. They are just invisible to the tools that have been protecting everything else for the last decade. CISA's KEV list and NIST's token guidance are the industry's way of saying that the invisibility is not a neutral state. It is the vulnerability. Close the inventory gap, authenticate every server, and bring the sessions under monitoring. Do that, and your agentic AI stack stops being the one part of your environment nobody watches. clone-systems.com
References
[1] Cloud Security Alliance, "MCP Security Crisis: Systemic Design Flaws in AI Agent Infrastructure," May 2026. https://labs.cloudsecurityalliance.org/research/csa-research-note-mcp-security-crisis-20260504-csa-styled [2] NIST, "Protecting Tokens and Assertions from Forgery, Theft, and Misuse (NIST IR 8587)," September 2026. https://csrc.nist.gov/News/2026/protecting-tokens-and-assertions-nist-ir-8587 [3] Tech Insider, "CISA Flags First MCP Flaw: LiteLLM CVE-2026-59822," September 10, 2026. https://tech-insider.org/litellm-mcp-vulnerability-cve-2026-59822-cisa-kev-2026/ [4] Clone Systems, CloneGuard AI assistant. https://www.clone-systems.com/cloneguard-ai-assistant/ [5] Clone Systems, Agent-based scanning. https://www.clone-systems.com/agent-based-scanning/ [6] Clone Systems, Managed SOC service. https://www.clone-systems.com/managed-soc-service/