One in Five MCP Access Policies Found Broken or Missing, Study Reveals

The Model Context Protocol's authorization model faces a reckoning. When a finance employee builds a scheduling tool over a weekend by describing it to an AI assistant, connects it to Slack and three internal APIs before dinner, and watches three departments depend on it by Monday, the real question becomes: what credentials is it actually running on?

The specification overhaul and what prompted it

On July 28, 2026, the Model Context Protocol's maintainers released a specification update centered almost entirely on authorization concerns: issuer validation, issuer-bound client credentials, and Client ID Metadata Documents as the standard registration mechanism. The move amounts to a tacit acknowledgment from the protocol's own creators that the original trust model failed under real-world conditions.

If the architects of the specification deemed such a comprehensive security revision necessary, tools hastily assembled without formal security review face even greater exposure. Most builders lack familiarity with issuer validation and related safeguards.

Three failure modes in practice

Tool descriptions function as executable instructions

Researchers at Invariant Labs demonstrated in May 2025 that GitHub's own MCP server could be compromised through a poisoned public issue. An attacker's text embedded in an issue body was interpreted as a directive by the agent, which then used the victim's token to access private repositories. The attack required no code modification or malicious tool deployment—merely an unsanitized description field.

A 2026 benchmark called MCPTox evaluated this vulnerability pattern across 45 operational MCP servers and 20 models, recording an average attack success rate of 36.5 percent, climbing to 72.8 percent against the lowest-performing model. The finance tool exhibits the same structural vulnerability: it processes Slack messages and ticket text to determine reprioritization decisions, unable to distinguish between legitimate coworker requests and engineered strings designed to mimic them, because no one specified that it should.

Permissions default to maximum scope

The typical failure stems not from absent permission models but from permission models that are simply disregarded. A server requiring read-only calendar access requests read, write, and admin permissions across the board because that is what the available tutorial demonstrated. Throughout the MCP ecosystem, 88 percent of servers require credentials to operate, yet only 8.5 percent actually implement OAuth.

Most deployments were never scoped to begin with, leaving no scope creep to prevent. The finance employee did not deliberate over appropriate scopes. Instead, he reused an admin-level API key sitting in his password manager from a reporting dashboard created two years prior, because obtaining a narrower credential would have required submitting a ticket—the very bureaucratic friction he sought to circumvent.

Static tokens persist without rotation or monitoring

Splunk's MCP Server app logged session and authentication tokens in plaintext until the fix arrived in version 1.0.3, designated as CVE-2026-20205. This occurred at a vendor with an established security organization.

Estimates suggest that more than half of MCP servers operating in production rely on static API keys or personal access tokens that undergo infrequent rotation. Nearly half of enterprise AI activity flows through personal accounts rather than service accounts, meaning the credential in use belongs to an individual's identity rather than the system itself.

The finance employee's token is that same reporting-dashboard key. It remains valid from the moment of issuance and will stay valid until someone remembers to revoke it. The sole record of what it accessed this month exists only in the employee's recollection—not in any audit log.

What the field research uncovered

During MCP integration work across customer and prospect deployments over recent months, a comprehensive review of MCP-related access policies revealed a troubling pattern.

We found that more than 20 percent of the MCP-related access policies we reviewed were either broken or missing entirely.

In the majority of cases, the MCP server in question was authenticated using a personal token rather than a service account. None of these tokens had a documented rotation schedule. None of the servers maintained logs of their activities. Had the finance employee's tool been included in that sample—and statistically it likely would have been—no one would have discovered the exposure until something failed, because currently nothing is actively monitoring for failure.

The necessary context

Not every hastily assembled integration requires a formal change advisory board. Most of what gets built on weekends is harmless. Requiring every informal project to pass through a rigorous review process recreates the eighteen-month procurement cycles that organizations have worked hard to escape. Governance carries its own price, measured in viable ideas that never materialize because procedural overhead extinguished the weekend momentum that made them possible.

The actual problem is not the existence of these tools. Rather, most organizations lack the visibility to distinguish between harmless integrations and those wielding tokens that reach production systems. They are attempting to solve this visibility gap using the same review mechanisms that motivated people like the finance employee to bypass them in the first place.

The core question for platform teams

Platform teams face a decision that has already been made for them. Whether to allow AI-built integrations was settled over a weekend, without any formal deliberation. The real choice is whether to understand what each MCP server can access through an intentionally constructed inventory, or to learn about it through an incident report after something goes wrong. The finance employee's scheduling tool continues operating. It has not caused an incident, and it probably never will.

The distinction between that tool and the next one that becomes a security incident is not the underlying code. It is whether anyone can articulate what token it holds, what systems it can reach, and when that token was last rotated.

Source: The New Stack