MCP Server Exposure Is a Cloud Security Problem

A protocol built to let AI agents reach enterprise tools has quietly become one of the easiest ways into enterprise clouds. Researchers tracking publicly reachable Model Context Protocol servers found the exposed population had nearly tripled in under a year, and a separate disclosure put the true scale, counting both public and inferred private deployments, in the hundreds of thousands. Neither figure describes a future risk. Both describe servers running today, many connected directly to Amazon Web Services, Microsoft Azure, patient records, and raw database access, with no authentication standing between an open port and the data behind it.

The pattern should be familiar to anyone who has watched enterprise AI adoption outrun enterprise security review. Teams stand up an MCP server to let an agent query a database, read a file store, or call an internal API, and the server ships with whatever defaults the quickstart guide used. Those defaults, in a large share of the servers researchers scanned, include no authentication, legacy transport protocols that broadcast responses to anyone listening, and credentials stored in plaintext configuration files. The agent gets its connective tissue. The enterprise gets a new, mostly invisible attack surface sitting outside the controls built for everything else.

This matters to Bonfy and Kiteworks customers for a specific reason that goes beyond "patch your servers." Patching closes the vulnerability researchers already found. It does nothing for the architectural assumption underneath MCP adoption, the assumption that the protocol layer, or the model's own judgment, will enforce what an agent is allowed to touch. Every exposed-server finding below is really the same finding restated. Enforcement that lives in the connection, the prompt, or the server configuration is enforcement that an attacker, a misconfiguration, or a careless deployment script can simply route around. Enforcement that lives at the data layer cannot be bypassed that way, because it never depended on the agent, the server, or the network path behaving correctly in the first place.

Key Takeaways

  1. Exposed MCP servers nearly tripled in under a year. Security researchers found the count of publicly reachable, unauthenticated MCP servers climbed from under 500 to roughly 1,467 in nine months, and a separate vendor disclosure estimated total exposure, public and private, in the hundreds of thousands once downstream deployments are counted.
  2. The exposure reaches directly into cloud accounts. Vulnerabilities disclosed against community MCP connectors for AWS and Azure scored 9.8 out of 10 on the CVSS scale, the range reserved for flaws that can hand an attacker full infrastructure control with minimal effort.
  3. Nearly half of scanned MCP server codebases store secrets insecurely. Researchers who reviewed more than 19,000 MCP server source trees found roughly 48 percent recommended or implemented storing API keys and credentials in plaintext files rather than a managed secrets vault.
  4. OWASP has already formalized the risk categories. The OWASP Top 10 for MCP names token mismanagement, privilege escalation through scope creep, tool poisoning, and shadow MCP servers as distinct, recurring failure modes, not edge cases.
  5. Patching the server is necessary and insufficient. Every disclosed MCP vulnerability assumes the server configuration, the network boundary, or the model's judgment is the control. A data layer that enforces what an agent can actually read or send holds even when all three fail at once.

What Changed Since the First MCP Exposure Scan

The first widely cited count of exposed MCP servers came from a scan that found 492 publicly reachable instances with no authentication layer in front of them. A follow-up scan nine months later found 1,467, a near tripling, and found that 1,227 of them, the overwhelming majority, were still running the legacy Server-Sent Events transport that the protocol's own maintainers consider deprecated. SSE broadcasts responses in a way that makes it straightforward for anyone with network visibility to read traffic that was never meant to leave the server's intended caller.

Bonfy's own tracking of MCP security statistics has followed this same exposure curve across 2026. A separate, independently sourced disclosure framed the scale differently and arrived at a far larger number. That research combined a count of publicly exposed instances with an inference about private deployments running the same vulnerable open source projects, and the combined estimate reached roughly 200,000 servers. The two figures are not measuring identical populations, and readers should treat the larger number as a directional estimate rather than a precise census. What both figures agree on is the direction. The installed base of MCP infrastructure is growing faster than the security practices around it, and the gap between those two curves is where the actual risk sits.

That gap shows up concretely in what researchers found running on exposed servers. A tool called execute_sql, which does roughly what its name suggests, was found reachable on dozens of hosts with no authentication gate in front of it. An agent memory system was found exposed on dozens more. At least a handful of servers exposed a feature built to let an AI assistant draft clinical progress notes directly against patient medical records, a configuration that would constitute a reportable healthcare privacy violation the moment an unauthorized party touched it.

Why AWS and Azure Connectors Scored a Perfect Severity Rating

Two vulnerabilities disclosed against a widely used, community maintained MCP connector for Amazon Web Services both carry a CVSS score of 9.8, the band reserved for flaws that are both trivial to exploit and catastrophic in outcome. A parallel disclosure affects Microsoft's own Azure MCP tooling. Disclosure in each case ran through the Zero Day Initiative, the coordinated vulnerability disclosure program that has become a standard clearinghouse for exactly this category of finding.

The mechanism in each case traces back to command injection. An MCP server that passes user supplied or agent supplied input into a shell command without strict sanitization gives an attacker a path to execute arbitrary commands with whatever privileges the server process holds. Where that process has access to the cloud provider's metadata service, the consequence is not contained to the server. It extends to the Identity and Access Management credentials the metadata service hands out, which in turn can unlock the broader cloud account, including data exfiltration, resource hijacking, and the kind of infrastructure sabotage that takes incident response teams weeks to fully scope.

This is also where the stdio transport design decision inside Anthropic's own MCP SDKs becomes relevant, not as a flaw exactly, but as a documented behavior that shifts responsibility onto every developer who builds on it. The SDK executes whatever command a host process supplies to spawn a server, without validating that the command actually starts a legitimate MCP server. Anthropic has described this as intentional, with input sanitization left as the implementing developer's responsibility. That is a reasonable design choice for a protocol library. It is a very large attack surface for an enterprise that assumes the platform vendor closed that gap on its behalf.

The Credential Problem Hiding Inside MCP Server Code

Exposure on the network is the visible half of the problem. The less visible half lives inside the server code itself, in how it manages the credentials it needs to talk to the systems it connects. A review of more than 19,000 MCP server source repositories found that roughly 48 percent recommended, documented, or implemented storing API keys and other secrets in .env files or plaintext JSON configuration, rather than in a managed secrets store.

That statistic matters more than it might first appear, because it describes a default that developers will copy forward by example. An MCP server built from a tutorial that stores its database credentials in a plaintext file becomes the template for the next five internal MCP servers a team stands up, each one inheriting the same insecure pattern without anyone making an active decision to accept that risk. Kiteworks' own research into this exact failure mode, documented in its reporting on Codex token theft found in a public npm package, showed the same pattern playing out in a different corner of the AI tooling ecosystem, a credential that should never have left a secrets manager, sitting in plaintext where a routine supply chain compromise could reach it.

Hardcoded credentials and insecure transport compound each other. A plaintext secret sitting on a server reachable over an unauthenticated, broadcast style transport is not a theoretical two-step attack. It is one scan away from a working exploit, and the scanning tools to find exposed MCP servers at internet scale already exist and are, in several of the research efforts cited here, explicitly built for that purpose.

Tool Poisoning and the Trust Problem Nobody Patches Away

A command injection vulnerability is a bug. Tool poisoning is a design-level trust problem, and it does not go away once every known CVE is patched. In a tool poisoning attack, a malicious or compromised MCP server returns a tool description, or a tool response, that misrepresents what it actually does or what data it actually touched. The agent consuming that response has no independent way to verify it. It trusts the server the same way it trusts any other tool result, because nothing in the architecture asks it to do otherwise.

Invariant Labs published early research into this exact failure mode, and the pattern has since been cited across multiple follow-on disclosures, including a backdoored npm package distributed under the name postmark-mcp that quietly exfiltrated email contents to an attacker controlled address while behaving normally in every other respect. The OWASP Top 10 for MCP formalizes tool poisoning, privilege escalation through scope creep, and shadow MCP servers, meaning MCP infrastructure that security teams never approved or inventoried, as distinct, named categories precisely because each one keeps recurring across unrelated codebases and unrelated vendors.

Shadow MCP servers deserve particular attention from a compliance standpoint, because they combine two failure modes that regulators treat separately but that show up together in practice. An unapproved MCP server is both unmonitored infrastructure and an unmonitored data access path, and an enterprise cannot produce an audit trail for a connection it did not know existed. Bonfy's own work on agentic data security treats this as the starting assumption rather than an edge case. Governance has to assume some share of MCP infrastructure in any sufficiently large enterprise is running without central visibility, and build enforcement that does not depend on discovering it first.

Why Protocol-Level Fixes Cannot Close This Gap Alone

Every recommendation attached to these disclosures is sound as far as it goes. Move secrets into a cloud native secrets manager. Deploy MCP servers inside private subnets rather than exposing them directly to the internet. Enforce OAuth 2.0 and role based access control on every server. Log every tool invocation so an incident response team has something to review after the fact. Containerize servers so a compromise does not automatically become a host compromise. Kiteworks has made a version of this same argument before, in Microsoft's own accounting of AI agent threats, which lists MCP plugin abuse as one of seven distinct failure modes enterprises need to plan around rather than treat as a single patchable bug.

The limitation shared by all of those fixes is architectural, not a matter of effort. Each one secures the server, the network boundary, or the credential store. None of them answers the question that actually determines the blast radius of a failure. Once an agent, or an attacker impersonating an agent, has reached a given MCP server, what specific data is that connection actually allowed to return, to whom, and under what conditions? Network segmentation and OAuth answer who can reach the server. They do not answer what the server is permitted to hand back once reached, and that is precisely the layer where tool poisoning, scope creep, and a misconfigured execute_sql tool all do their damage.

This is the same argument Kiteworks has made about CISA's agentic AI guidance, which draws a clear line around audit trails and access boundaries as the controls that matter once an agent is already operating, rather than only the controls that try to keep it from operating somewhere it should not. A server that is correctly authenticated, correctly network segmented, and still configured to hand back an entire customer table to any authenticated caller has solved the access problem and left the data problem completely open.

What the Data Layer Catches That the Server Configuration Cannot

Bonfy's broader position is that agents cannot self-secure, and the research above is a direct illustration of why. Data layer enforcement does not compete with the protocol level fixes above. It assumes they will sometimes fail, because the research cataloged in this post shows they already have, repeatedly, across unrelated vendors and unrelated codebases, and it puts a control at the one point that every one of those failures still has to pass through, the actual content leaving the system. Contextual data enforcement evaluates what a specific response contains and who is asking, in real time, rather than trusting that the server, the transport, or the agent's own instructions already made that determination correctly.

Concretely, that means an MCP tool call that returns patient records, full database tables, or agent memory containing prior conversation history gets evaluated against policy at the moment of return, independent of whether the server that generated it was itself compromised, misconfigured, or simply running on defaults nobody reviewed. Bonfy's MCP Server was built specifically around this principle. The enforcement point sits at data-in-use, inspecting and governing what moves through an agent workflow in real time, rather than relying on the upstream server's own configuration to have gotten access control right. This is also the thesis behind Kiteworks' broader argument that agentic AI security needs a runtime security layer, not only a perimeter, because the perimeter is exactly what these disclosures keep breaching.

For the compliance and audit function specifically, this distinction has a very practical consequence. An organization that can show a regulator or an assessor a continuous, content aware log of what an AI agent actually accessed and returned through every MCP connection, sanctioned or shadow, is in a fundamentally different position than one that can only point to a firewall rule and hope the server behind it was configured correctly. The first produces evidence. The second produces an assumption, and assumptions are precisely what fail when the server in question is one of the 1,467 that researchers found exposed, or one of the thousands that nobody has scanned yet.

How CISOs and Compliance Leaders Should Prioritize This Gap

Treating this as purely an infrastructure patching exercise undercounts the exposure. A security team that inventories and patches every known MCP server it manages has addressed the servers it already knew about. The 1,467 exposed instances researchers found, and the far larger population implied by the 200,000 estimate, exist precisely because most of these servers were never on anyone's asset inventory in the first place. They were stood up by a developer solving an immediate problem, using a default configuration from a quickstart guide, with no security review because no formal process existed to trigger one.

The practical response starts with accepting that shadow MCP servers are a near certainty in any enterprise with active AI agent adoption, not a hypothetical. From there, the priority shifts from "find every server" (worth doing, never fully achievable on a continuous basis) to "make the data returned through any server, found or unfound, subject to the same enforcement." That reframing is what lets a CISO or compliance lead make a defensible statement to a regulator or a board. Not that every MCP server is accounted for, which research suggests is not realistically achievable at enterprise scale, but that no MCP connection, inventoried or not, can return regulated data without that access being evaluated, logged, and defensible after the fact.

Frequently Asked Questions

1. What is an exposed MCP server, and why does it matter?

An exposed MCP server is a Model Context Protocol server reachable from the public internet, or from an internal network segment broader than intended, without authentication controls blocking unauthorized access. It matters because MCP servers exist specifically to give AI agents access to enterprise systems like databases, file stores, and internal APIs, so an exposed server is effectively an unguarded door directly into whatever that server connects to, including, in cases researchers have documented, patient records and cloud account credentials.

2. How many MCP servers are currently exposed?

A scan focused on publicly reachable, unauthenticated instances found the count had grown from under 500 to roughly 1,467 over roughly nine months. A separate disclosure estimated total exposure, combining public instances with inferred private deployments running the same vulnerable open source projects, at approximately 200,000. The two figures measure different populations and should not be added together, but both point toward exposure growing faster than remediation.

3. Are AWS and Azure directly at risk from MCP vulnerabilities?

Yes, in documented cases. Vulnerabilities disclosed against a community maintained MCP connector for Amazon Web Services, and against Microsoft's own Azure MCP tooling, both reached a CVSS severity score of 9.8, reflecting flaws that could allow command injection leading to access to cloud Identity and Access Management credentials, and from there to broader account compromise, data exfiltration, or resource hijacking.

4. Can patching MCP server vulnerabilities fully solve this problem?

Patching closes the specific vulnerabilities researchers have found and disclosed, which is necessary. It does not address MCP servers that were never inventoried in the first place, often called shadow MCP servers, and it does not change the underlying architectural assumption that the server configuration or the agent's own judgment will correctly enforce what data a given connection is allowed to return. Data layer enforcement addresses that second gap directly, by evaluating the content of a response at the point it is returned, independent of whether the server generating it was itself correctly configured.

5. What should a compliance team ask about MCP server governance today?

A compliance team should ask whether the organization has a current, complete inventory of every MCP server in production, whether credentials used by those servers are stored in a managed secrets vault rather than plaintext configuration, and, most importantly, whether there is a way to demonstrate what data any given MCP connection actually returned over a defined period. That third question is the one most organizations cannot currently answer, and it is the one a regulator or auditor is most likely to ask first.

To learn more about agentic AI governance, schedule a custom demo.