MCP servers are exploding in enterprise use and lagging badly on security. Independent security audits conducted since 2025 and compiled into 2026 industry reporting put anywhere from 30 percent to 82 percent of public Model Context Protocol servers carrying an exploitable flaw such as path traversal, server-side request forgery, or command injection, only 8.5 percent of servers use OAuth for authentication, and 88 percent of organizations reported a confirmed or suspected AI agent security incident in the past year. The mechanism behind nearly every one of those numbers is mundane: missing authentication, secrets returned in plain text, and ordinary web application bugs, now sitting behind a caller with the speed and persistence of an autonomous agent rather than a human clicking through a browser.
Model Context Protocol adoption has moved faster than almost any developer standard in recent memory. Anthropic's own count put monthly SDK downloads above 97 million by December 2025, with more than 10,000 active public servers and first-class client support across ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code. Team8's 2025 CISO Village Survey found 70 percent of enterprises already running AI agents in production, with another 23 percent planning deployment in 2026.
Security maturity has not kept pace. Endor Labs found that 82 percent of MCP implementations handle file operations in a way prone to path traversal, across 2,614 servers examined. A separate Equixly assessment found 43 percent of tested servers vulnerable to command injection. BlueRock Security found 36.7 percent of more than 7,000 servers vulnerable to server-side request forgery, and Enkrypt AI found 33 percent of 1,000 scanned servers carrying a critical vulnerability. On the authentication side, an Astrix audit of more than 5,200 servers found that while 88 percent require some form of credential, 53 percent rely on static API keys or personal access tokens, 79 percent pass those keys through environment variables, and only 8.5 percent use OAuth at all. Trend Micro's own internet scan found 492 MCP servers exposed publicly with no authentication or encryption at all, a figure that nearly tripled to 1,467 in a follow-up count.
The incident data tracks the exposure. HiddenLayer's 2026 AI Threat Report found autonomous agents now account for more than one in eight reported AI breaches. Gravitee's 2026 survey found 88 percent of organizations reported a confirmed or suspected AI agent incident in the past year, rising to 92.7 percent in healthcare specifically. HackerOne's ninth annual report logged a 540 percent surge in prompt-injection vulnerability reports, calling it the fastest-growing threat category in AI security, alongside more than 30 MCP-related CVEs filed in a single 60-day window in early 2026. Gartner's own forecast, that 25 percent of enterprise breaches will trace to AI agent abuse by 2028 and that more than half of successful attacks on AI agents through 2029 will exploit access-control issues, is not a hypothetical extrapolation. It is a straight-line projection from numbers that are already this large.
If one event captures where MCP security stands in September 2026, it is the Deadbugz campaign. A single GitHub account filed 23 pull requests across unrelated AI and developer tool projects in 74 minutes, each one offering a small, plausible-looking MCP server for text formatting and summarization. Reviewers who checked the server before merging it found nothing wrong, because there was nothing wrong yet. The server behaves exactly as advertised for the first three tool calls. Only after that does its metadata rewrite itself into instructions hunting for SSH keys, AWS credentials, shell history, and Kubernetes configuration files, while concealing the activity from the user running it.
That design defeats one-time review by construction. A security team that scans a new MCP server once before approving it, the standard practice at most organizations today, will see a clean report, because the payload does not exist at scan time. It only exists once the server has been trusted, connected, and used. The practical lesson researchers drew from Deadbugz is to monitor tool metadata for changes after approval rather than treating a single pre-approval scan as sufficient, and to compare tool definitions on every reconnect if a client caches them, since drift after the fact is the signal a one-time audit cannot catch.
The same month's CVE disclosures reinforce a related point: most of what is going wrong with MCP servers has nothing to do with the language model calling them. CVE-2026-73498 affects the Atlassian Confluence MCP tool, where the confluence_upload_attachment function passed a client-supplied file path directly into a file-open call with no validation, giving any authenticated client an arbitrary file read across everything the server process could reach. CVE-2026-67357 hit ArcadeDB, where a settings tool exposed over MCP returned its high-availability cluster token in cleartext, a token that was enough on its own to impersonate root through specific request headers. CVE-2026-19956 affected a Facebook Ads MCP server, where a server-side request forgery flaw in a pagination function let an authenticated remote caller drive requests from the server's own network position.
None of these three involved prompt injection, model manipulation, or anything specific to how an LLM reasons. They are a path traversal, a secrets-handling failure, and an SSRF bug, the same three vulnerability classes that show up in ordinary web application security reviews every week. What changed is the caller. An MCP server exposes ordinary application logic to an extraordinary caller, one capable of making thousands of consistent, tireless tool calls at machine speed, and the same class of bug that a human tester might eventually stumble onto becomes something an agent can find and exploit as a routine step toward whatever goal it was given.
Most enterprise MCP governance today is built around a configuration question: which servers are connected, which tools are exposed, which scopes were granted. That question matters, but Deadbugz shows why it is not enough on its own. A server that passes every configuration check can still turn hostile after approval, and a tool that was correctly scoped can still leak a token it was never supposed to return, as in the ArcadeDB case. Researchers studying compromised MCP environments have also documented a cross-server cascade effect, where compromising one server in a multi-server agent workflow propagates to others at a rate above 70 percent, which means the blast radius of a single bad server is rarely contained to that server alone.
This is the gap Bonfy's Contextual Data Enforcement architecture is built to close. Rather than stopping at what a server or tool is configured to do, it inspects the content an agent retrieves and produces at the point of use. Bonfy's own MCP server lets an agent call in mid-reasoning, "is this safe to use," and receive an entity-aware risk assessment before it proceeds, rather than after a summary has already gone out or a file has already moved. Most tools ask what an agent is configured to do. Bonfy asks what data is actually flowing through it, which is the only question that would have mattered against a server like Deadbugz's, since its configuration looked correct right up until the third tool call.
Bonfy's own product architecture reflects the same lesson the industry statistics point to. As the company put it when describing why AI agents alone will not secure agentic AI, the real control point sits at the data layer, not inside the agent's own reasoning, because an agent cannot be relied upon to police content it has already decided it needs.
Contextual enforcement at the point an agent reasons over content addresses one half of what the statistics above expose. The other half is the exchange layer underneath every MCP interaction, the authentication, encryption, and audit trail that determine whether a compromised or careless server can reach sensitive content at all.
Kiteworks' Secure MCP Server, which shipped on Anthropic's Connector Marketplace earlier in 2026, addresses that layer directly, and it is built around a distinction the Astrix authentication data makes obvious is missing across most of the ecosystem: every Kiteworks customer runs its own private cloud instance, so each organization deploys its own private MCP server rather than connecting to a shared, multi-tenant endpoint the way a public registry server typically works. The server enforces OAuth 2.0 authentication, applies attribute-based access control to every request at the data layer, and produces full audit logging for every agent action, addressing directly the gap Astrix found in only 8.5 percent of public servers using OAuth at all. Kiteworks' MCP integration for secure AI never exposes raw file contents to the model itself; the model receives structured results from a governed request rather than a direct path to the underlying repository. That architecture, a governed intermediary between the model and the raw file system rather than a tool function with direct filesystem access, is the design principle the Atlassian and ArcadeDB advisories show was missing: both flaws turned a single tool call into direct, unmediated access to a file path or a settings store.
The Kiteworks Developer Portal documents this for developers building against the same REST API and MCP surface, including setup guides for connecting Claude and Microsoft Copilot Studio to a governed MCP endpoint rather than an ungoverned one. Put together with Bonfy's inline inspection at the point of use, this gives an organization coverage across both halves of the MCP risk data: what an agent's server does with the content it touches, and whether the channel carrying that content is authenticated, encrypted, and logged to a standard an auditor can rely on.
The statistics above describe an ecosystem, not a specific organization's exposure, and the gap between the two is closeable without waiting for the industry average to improve. Start by auditing every MCP server your organization has connected against the three vulnerability classes behind nearly every CVE disclosed this year: unvalidated file paths, secrets returned in tool output, and unvalidated outbound requests, the same data governance gap that shows up whenever an agent's data access outpaces the scrutiny applied to it. Move any server still relying on a static API key toward OAuth 2.0, given how directly the authentication gap correlates with the exposure numbers above. And build in inspection that runs after approval, not just before it, since Deadbugz proved that a clean pre-approval scan tells you nothing about what a server will do on its fourth tool call.
1. How many MCP servers have exploitable vulnerabilities, based on the 2026 data?
Estimates vary by methodology and vulnerability class, but every independent audit published in 2026 found a substantial share exposed. Endor Labs found 82 percent of 2,614 implementations handled file operations in a way prone to path traversal, Equixly found 43 percent vulnerable to command injection, and Enkrypt AI found 33 percent of 1,000 scanned servers carried a critical vulnerability. One caveat worth noting: an independent audit of YARA-based MCP scanners found a false-positive rate near 78 percent, so raw percentages vary meaningfully by how a study measured "vulnerable."
2. What was the Deadbugz campaign, and is it still active?
Deadbugz is a supply chain campaign that distributed a malicious MCP server through GitHub pull requests, filing 23 of them across unrelated projects in 74 minutes from a single account. The server behaves normally for its first three tool calls, then rewrites its own tool metadata into instructions that hunt for SSH keys, cloud credentials, and shell history. Researchers who documented it described it as an actively distributed campaign at the time of disclosure in September 2026.
3. Why does MCP authentication lag so far behind adoption?
The Model Context Protocol's own June 2025 specification revision recommends OAuth 2.1 with PKCE and separates the resource server from the authorization server, but adoption of that guidance has been slow. Astrix's audit of more than 5,200 servers found only 8.5 percent using OAuth, with the majority relying on static API keys or personal access tokens, often passed through environment variables where they are easier to leak than to rotate.
4. How would Bonfy and Kiteworks divide the work in securing an MCP deployment?
Bonfy's Contextual Data Enforcement inspects what an agent retrieves and produces during reasoning, catching a server that behaves correctly at approval time and turns hostile later, the exact pattern Deadbugz demonstrated. The Kiteworks Secure MCP Server governs the exchange layer underneath that reasoning: private per-customer deployment, OAuth 2.0 authentication, attribute-based access control, and full audit logging on every request. One inspects what the agent does with content; the other governs whether the agent's server can reach that content in an authenticated, logged way in the first place.
5. Do you need both Bonfy and Kiteworks, or does one replace the other?
They cover different layers of the same problem. A governed MCP server without content-level inspection would still be exposed to a server that passes every configuration and authentication check and turns hostile after approval, as Deadbugz did. Content-level inspection without a governed exchange layer would still leave an organization without the private deployment, OAuth enforcement, and audit trail that the Astrix and Trend Micro data show are missing across most of the public MCP ecosystem. Organizations running agents against sensitive enterprise data need both layers, not one or the other.
6. What is the single highest-leverage fix for an organization running MCP servers today?
Based on the 2026 data, closing the authentication gap has the broadest effect: moving every server off static API keys and onto OAuth 2.0 addresses the root cause behind a large share of the exposure Astrix and Trend Micro documented, since a server with proper authentication and scoping is far harder to reach in the first place, regardless of what bugs exist in its code. See Kiteworks' Secure MCP Server overview for what that looks like in a governed deployment.
The MCP ecosystem is not going to wait for its security maturity to catch up to its adoption curve, and neither should the organizations connecting agents to sensitive enterprise data today. See how Bonfy's Contextual Data Enforcement and the Kiteworks Secure MCP Server close both halves of the gap the 2026 data exposes at bonfy.ai and developer.kiteworks.com, or schedule a demo to see contextual enforcement applied to your own MCP deployments.
Gidi Cohen, VP Product, Kiteworks
Gidi Cohen is VP Product at Kiteworks and the co-founder and former CEO of Bonfy.AI, which Kiteworks acquired in September 2026. He previously spent over a decade leading Skybox Security as CEO and founder.