The Permission Boundary That Did Not Hold
The most direct challenge to MCP's enterprise readiness came from a developer who was not trying to break anything. Testing read-only calendar access through Zapier's MCP integration, the developer explicitly set read-only permissions — and then watched their agent successfully create a new Google Calendar event anyway . The test was designed to observe a failure that did not arrive. What arrived instead was an unauthorized write, executed cleanly, with no error surfaced to the user.
This is the specific failure mode that makes MCP governance different from conventional API access control. The protocol is designed to give agents broad action capability through a unified tool interface — the same design property that makes it powerful is what makes permission scoping at the MCP layer unreliable when the underlying service does not enforce its own constraints. The Zapier incident may reflect a connector-specific implementation gap, but the community reading it is drawing the correct structural inference: MCP servers relay permission boundaries rather than enforce them, and relay is not enforcement.
The Enterprise Denial Trap
Full denial is not a stable security posture for organizations where developer demand is both large and documented. The enterprise engineer who surfaced the governance question — managing a developer population of roughly 3,500 with approximately 1,000 actively requesting MCP access — was explicit about the alternative to sanctioned adoption: developers use personal laptops with their SSO credentials and treat it as invisible . Security policy that cannot be enforced at the margin does not reduce risk; it relocates risk outside institutional visibility.
The governance infrastructure being requested — an MCP server catalog with an approval workflow, OAuth scoping at the server level, and a vetting mechanism before any server touches production — does not exist in standardized form. Individual enterprises are building it themselves or waiting for someone else to build it first. The developers who cannot wait are already on the shadow path, and the organizations that believe denial is holding have no reliable way to verify that assumption.
The Threat Surface Is Already Documented
The tool-poisoning finding — real attacks identified in a scan of more than 150 MCP servers on GitHub — landed in a community where the dominant activity is capability expansion, not threat modeling. The same period produced MCP servers for Shopify store management , PDF processing for RAG pipelines , dynamic REST API proxying , and structured deep-research workflows . None of these projects are malicious; most represent genuine practitioner ingenuity. The problem is that tool-poisoning attacks work precisely by exploiting the trust that practitioner ecosystems generate — a malicious tool description can redirect agent behavior silently, at the point where the agent reads its available tools rather than when it executes an action.
The agentic AI failure modes already in production do not require novel attack sophistication. They require only that an agent extend trust to a tool description it cannot verify — and MCP's architecture makes this the default unless a consuming application explicitly validates server provenance, which no standard currently requires.
Anthropic's Protocol Cadence Versus Enterprise Readiness
Anthropic's positioning frames MCP as the infrastructure layer that makes agent execution efficient , and the SDK release cadence supports that ambition — four version increments across Python and TypeScript implementations in under four months . That pace reflects a protocol being actively extended, not stabilized. Version increments at this frequency typically signal capability expansion rather than security hardening.
The HTTP analogy that has taken hold in practitioner communities is useful precisely because it is incomplete. HTTP became safe for enterprise use only after years of security primitives were added on top — authentication, transport encryption, cross-origin controls, certificate infrastructure. MCP is at the moment before those primitives. The difference between HTTP's pre-SSL era and MCP's current state is that agents are executing consequential actions through MCP today, not serving static documents. The security debt being accumulated is active exposure, and the SDK releases show no sign that closing it is the current priority.
What Governance Will Actually Require
The governance pattern that enterprise practitioners are assembling in forum posts — catalog-based approval, server-level OAuth scoping, provenance verification — is not a feature list waiting for Anthropic to ship. It is a structural requirement that only makes sense as a shared standard, built either by Anthropic, by a consortium of major MCP consumers, or by the open-source community that has already started building catalog and proxy infrastructure . The enterprises waiting for that standard before expanding access are making a defensible bet.
The developers building around MCP without it are accumulating an integration surface that will need to be audited retroactively — and retroactive audits of agentic systems that have been writing to production calendars and managing Shopify stores are not simple. The version of MCP that enterprises can safely deploy at scale requires explicit server identity, verifiable tool descriptions, and permission enforcement that does not depend on the consuming agent to enforce. The builders writing governance requirements in community threads today are ahead of any formal standard — and when that standard arrives, it will copy them.