More than 20 percent of access policies tied to Model Context Protocol integrations are either broken or missing entirely, according to findings published by The New Stack in September 2026. The report examines the security gaps that emerge when employees build AI-powered tools quickly—often over a weekend—and wire them into internal systems without formal oversight. The core issue isn't that these tools exist, but that most organizations can't tell which ones hold credentials that reach production data until something goes wrong.
The report details three failure patterns that define the current state of MCP security. A 2026 benchmark called MCPTox tested prompt injection attacks against 45 live MCP servers and 20 models, recording a 36.5 percent average attack success rate and 72.8 percent against the worst-performing model. In May 2025, researchers at Invariant Labs demonstrated that GitHub's own MCP server could be hijacked through a poisoned public issue—an attacker's text in an issue body was interpreted as an instruction by the agent, which then used the victim's token to extract data from private repositories. Across the MCP ecosystem, 88 percent of servers require credentials to function, but only 8.5 percent actually use OAuth. By some estimates, over half of MCP servers in the wild run on static API keys or personal access tokens that are rarely rotated, and close to half of enterprise AI activity runs through personal accounts rather than service accounts. Splunk's own MCP Server app logged session and auth tokens in cleartext until it was patched in version 1.0.3, tracked as CVE-2026-20205.
The report notes that on July 28, 2026, the Model Context Protocol's maintainers shipped a specification update built almost entirely around authorization: issuer validation, issuer-bound client credentials, and Client ID Metadata Documents as the preferred way for clients to register. According to the report, that update represents the protocol's own stewards admitting the original trust model didn't survive contact with production. In the MCP-related access policies the authors reviewed across customer and prospect environments over the past several months, the MCP server in question was authenticated with someone's personal token rather than a service account in most cases, none of those tokens had a documented rotation schedule, and none of the servers had logs of what they touched.
The underlying problem is structural, not technical. The common failure isn't a missing permission model; it's an ignored one. A server that needs read-only calendar access asks for read, write, and admin across the board because that's what the tutorial used, and scopes default to everything when nobody is prompted to narrow them. Employees bypass formal procurement processes specifically because those processes are slow, but the tools they build instead carry admin-level API keys that were issued years ago for unrelated projects and have never been rotated. Gating every weekend project behind a formal review process is exactly how you get back to the eighteen-month procurement cycle nobody missed, but governance has its own cost, paid in the good ideas that never ship because process ate the weekend momentum that made them possible. The report frames the actual decision platform teams face as whether they find out what a given MCP server can touch from an inventory they built on purpose, or from an incident report after the fact. The difference between a harmless scheduling tool and the next one that makes the news isn't the code; it's whether anyone can say what token it holds, what it can reach, and when it was last rotated. The tension isn't between velocity and safety—it's between building visibility into what already exists and pretending the old approval process still controls what gets deployed. Most organizations are learning that the latter is a fiction they can't afford to maintain.