The Model Context Protocol's authorization model is colliding with the reality of rapid, informal AI tool development. Consider a finance employee who describes a scheduling application to an AI assistant on a Sunday afternoon, integrates it with Slack and three internal APIs before dinner, and by Monday has three departments depending on it. The scenario becomes troubling once you examine which credentials the tool is actually running under.
What changed a few weeks ago
On July 28, 2026, the Model Context Protocol's maintainers released a specification update centered almost entirely on authorization: issuer validation, issuer-bound client credentials, and Client ID Metadata Documents as the standard registration method. The move amounts to an acknowledgment from the protocol's creators that the original trust model failed to withstand real-world deployment conditions. If the specification's authors required such a comprehensive security overhaul, hastily assembled tools built without security expertise certainly do not merit exemption.
Three ways this actually breaks
Tool descriptions 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: attacker-controlled text in an issue body was interpreted as an instruction by the agent and executed using the victim's token to retrieve data from private repositories. No code compromise or malicious tool was required—only an unsanitized description field.
A 2026 benchmark called MCPTox evaluated this vulnerability pattern against 45 live MCP servers and 20 models, recording a 36.5 percent average attack success rate and 72.8 percent against the lowest-performing model. The finance tool exhibits the same fundamental architecture: it processes Slack messages and ticket text to determine reprioritization decisions. It cannot distinguish between legitimate coworker requests and engineered strings designed to mimic them, because no one specified that it should.
Scopes default to everything
The typical failure stems not from absent permission models but from ignored ones. A server requiring read-only calendar access requests read, write, and admin permissions across all resources because that is what the tutorial demonstrated. Within the MCP ecosystem, 88 percent of servers require credentials, yet only 8.5 percent actually implement OAuth.
Most deployed systems were never scoped intentionally, leaving no scope to creep. The finance employee did not deliberate over appropriate access levels. Instead, he reused an admin-level API key from his password manager, originally created for a reporting dashboard two years prior, because requesting a narrower credential would have required filing a ticket—the exact bureaucratic friction he sought to circumvent.
Static tokens without rotation or visibility
Splunk's MCP Server app logged session and authentication tokens in plaintext until version 1.0.3 addressed the issue, tracked as CVE-2026-20205. This vulnerability affected a vendor with a dedicated security team. Industry estimates suggest that over half of MCP servers operating in production rely on static API keys or personal access tokens that are infrequently rotated. Nearly half of enterprise AI activity flows through personal accounts rather than service accounts, meaning the credential performing the work belongs to an individual's identity rather than a system identity.
The finance tool's token is that same reporting-dashboard key. It remains valid since issuance and will persist until someone revokes it. The only record of what it has accessed this month exists in the employee's memory—not in any audit log.
What we have actually seen
During MCP integration deployments across customer and prospect environments over several months, a 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 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 actions. Had the finance tool been included in this sample—and statistically it likely would have been—no one would have discovered the risk until something failed, because currently nothing is monitoring for failure.
The honest caveat
Not every AI-built integration requires a change advisory board. Most of what the finance employee created is harmless, and requiring every weekend project to pass formal review recreates the eighteen-month procurement cycles that organizations have worked to escape. Governance carries its own price, measured in valuable ideas that never materialize because process consumed the weekend momentum that made them viable.
The actual problem is not the existence of these tools. It is that most organizations cannot currently distinguish between harmless integrations and those wielding tokens with production reach, and they are attempting to solve this using the same review apparatus that motivated Bob to bypass formal channels in the first place.
The actual decision
Platform teams face a choice that has already been made for them: whether to discover what an MCP server can access through an intentional inventory, or through an incident report. The finance tool continues operating. It has not caused an incident, and it probably never will. The distinction between this tool and the next one that becomes a security incident is not the underlying code—it is whether anyone can identify what token it holds, what systems it can reach, and when that token was last rotated.
Source: The New Stack