Est.
FeaturesLong read

Why MCP Governance Decisions Made Now Will Be Hard to Undo

Columnist · · 10 min read
Cover illustration for “Why MCP Governance Decisions Made Now Will Be Hard to Undo”
Features · August 9, 2026 · 10 min read · 2,260 words

There is a concept in economics called path dependence: when adoption has increasing returns, early choices compound, and the cost of switching eventually grows faster than any conceivable benefit of switching. The original choice becomes canonical, not because it was optimal, but because the ecosystem built on top of it makes revision prohibitively expensive.

MCP launched in November 2024. By March 2026, it had reached 97 million monthly SDK downloads, up from roughly 2 million at launch. The milestone trajectory tells the story in three beats: 45 million installs when Microsoft shipped MCP across Copilot, 68 million when AWS joined, 97 million by early 2026. Today, 78% of enterprise AI teams have MCP-backed agents in production, and 28% of Fortune 500 companies run MCP servers, up from 12% just one quarter prior.

Those numbers don't describe a product. They describe a protocol becoming infrastructure.

Protocols behave differently than products at scale, and the historical record on this is unambiguous. IBM's SNA and DEC's DECnet dominated enterprise environments as closed ecosystems before open standards eroded them, but that erosion took a decade and left stranded costs everywhere it touched. TCP/IP didn't win in the early 1990s because it was objectively superior on day one; it won because the network effects of an open standard overwhelmed proprietary alternatives. HTTP, Linux, Kubernetes: each became safe to build production systems on precisely because no single vendor could unilaterally alter them. That stability is also the mechanism of lock-in, because the entire ecosystem builds atop whatever the early spec said, and the early spec is rarely the final word.

MCP is generating those same positive feedbacks right now. Stripe, Cloudflare, JetBrains, Replit, and over 9,400 public servers are all producing tooling, documentation, and integrations that assume MCP's current architecture. BCG has characterized the core value proposition this way: without MCP, integration complexity scales quadratically as agents proliferate; with it, linearly. Any organization that has felt the relief of that efficiency gain will not voluntarily return to quadratic complexity. That relief is itself a lock-in force.

The implication is this: governance decisions made now aren't being made against a blank slate. They're being made at the moment the architecture is hardening.

Diagram: MCP's Explosive Adoption in Four Milestones. Visualizes: Visualize the growth trajectory of MCP monthly SDK downloads from launch (November 2024) through early 2026, anchored by four concrete milestones: ~2 million at launch, 45 million…

What MCP's governance structure actually locks in — and what it leaves open

Venn diagram: MCP Governance: Protections vs. Gaps. Compares AAIF Structure Protects and AAIF Structure Leaves Open; overlap: Both Lock In.

In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI. The AAIF launched with over 150 member organizations and eight platinum sponsors: AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI.

What the AAIF structure genuinely protects is worth naming. The protocol specification, trademark, domain, and GitHub organization are no longer Anthropic's to unilaterally change. The Specification Enhancement Proposal process, introduced in mid-2025, requires multi-stakeholder consensus for changes. Seven working groups stood up in early 2026, covering Identity and Trust, Security and Privacy, Observability and Traceability, Governance Risk and Regulatory Alignment, and adjacent areas. These are the bodies that will shape what the spec demands of enterprise implementations.

What the AAIF structure does not protect gets far less discussion, and that gap is where the real governance risk lives.

Multi-stakeholder consensus makes breaking changes extraordinarily difficult. Decisions embedded in the spec early become canonical because reversing them requires over a hundred members and eight competing platinum sponsors to agree. NIST's AI Agent Standards Initiative now names MCP explicitly as an interoperability framework it will foster, meaning regulatory bodies are building atop the current spec and compounding the cost of revising it. Open questions remain: whether the technical steering committee holds when Anthropic's and OpenAI's interests diverge on a specific feature; whether 150-plus members translates to active contributors or mostly passive affiliation; whether a committee process can keep pace with the velocity of agentic AI development.

The governance structure has successfully neutralized the risk of vendor capture. In doing so, it has made the spec's current shape more durable. Enterprises that build their internal governance on assumptions about what the spec does and doesn't require are now building on something no single actor can quickly change on their behalf. That is both a protection and a constraint, and most organizations are only pricing in the first half.

The security gaps baked into early MCP deployments and why they compound

A scan of 1,000 MCP servers found critical vulnerabilities in a third of them. A separate scan of over 1,800 servers found some security finding in nearly two-thirds. Only 29% of organizations feel prepared to secure agentic AI applications, per Cisco's State of AI Security 2026 report. These are not the numbers of an ecosystem that prioritized security from the start.

The structural reason is a governance problem, not merely a security one. MCP originally prioritized interoperability. Authentication, authorization, and audit logging were post-hoc additions rather than original design requirements. The attack surface this created has been formally documented. CVE-2025-49596, with a CVSS score of 9.4, allowed arbitrary command execution through unauthenticated MCP Inspector instances. Two formally named CVEs defined the tool-poisoning attack class, demonstrating exploitation through the same structural gap via different mechanisms. A 2026 disclosure identified hundreds of thousands of vulnerable MCP instances across IDEs, internal tools, and cloud services.

Research on multi-server cascade failures in compromised MCP meshes puts the propagation rate above 70%. That number deserves a moment. It means a single ungoverned server is not a bounded risk; it is an entry point to a much larger failure, one that propagates precisely because the connections between servers are the feature. A compromised MCP server in a mesh of agents is less like a cracked window and more like a seized bearing in a drive shaft: the damage doesn't stay local.

MCP lacks standardized audit logging in its protocol specification. Organizations must implement it at the gateway layer themselves. Every MCP server added without a registry entry, access control, or audit hook is not just a current risk; it is governance debt that accrues interest. Retrofitting controls onto a large, distributed installed base is categorically harder than building them in from the start, and the risk across a growing ungoverned estate is not additive. It compounds.

How regulatory timelines are turning governance choices into compliance architecture

The EU AI Act is the sharpest near-term constraint. Enforcement powers became active in August 2026, with penalties reaching up to tens of millions of euros or 6% of global annual turnover for the most serious violations. The exposure is broader than most enterprises have modeled.

If an AI agent calls APIs, including MCP servers, that action layer falls under the Act's cybersecurity and logging mandates. In multi-agent architectures, every agent in the chain performing a high-risk function is in scope; the compliance boundary extends to the entire action layer, not just the model. The Act's transparency and accountability requirements were designed for AI systems with defined boundaries and predictable behavior. MCP eliminates both assumptions.

The compounding dynamic here is underappreciated. Once enterprises build compliance programs, audit trails, and regulatory attestations around MCP's current architecture, reverting or re-architecting becomes legally expensive, not just technically expensive. The compliance record itself becomes an argument against changing what the record was built to attest. Organizations don't just inherit their technical choices; they inherit their documented governance posture, and regulators treat that posture as a baseline.

Global AI governance spend is growing sharply through the early 2030s, and the driver is not innovation enthusiasm. It is compliance deadlines. That spend hardens governance choices into vendor relationships and contractual obligations that outlast any single product cycle.

International coordination through OECD principles and the AI Safety Summit series has produced soft law but not binding cross-border standards. Enterprises are therefore making governance architecture decisions before the regulatory picture is fully resolved. That ambiguity is itself a form of early lock-in: choices made now, in the absence of clear rules, become the baseline against which future rules are assessed. Waiting for clarity is not a neutral position. It is a position.

The decisions that feel tactical now but function as architecture later

Diagram: Governance Decisions and Their Compounding Costs. Visualizes: Show three tactical decisions — registry, access control, audit logging — each presented as a fork between the low-cost early path and the high-cost retrofit path.

Consider the registry question first, because it has the most direct cost structure. Every MCP server added to production without a central registry entry is a governed identity that cannot be accounted for later. As the server count grows, a registry retrofit requires re-auditing the entire installed base. The cost of that audit scales with the size of the problem you deferred, not with the size of the problem as it existed when deferral felt reasonable.

Access control architecture is adjacent and frequently confused with a configuration decision. It is not. Role-based access control for AI agents is an architectural choice. Organizations that implement agent permissions as individual server-level settings rather than as a centrally enforced policy layer will find that policy changes require touching every server separately, with no guarantee of consistency across the estate. The operational burden grows with every server added to the ungoverned perimeter.

Audit logging placement has the longest compliance tail of any of these. Organizations relying on application-level or model-level logging rather than gateway-layer logging are building audit coverage with structural gaps baked in. When the compliance question arrives, those gaps cannot be retroactively filled. The events that weren't captured are gone.

Transport and extension choices carry longer consequences than they initially appear to. The selection of Streamable HTTP as a transport was made partly to prevent ecosystem fragmentation, but it constrains horizontal scaling in specific architectures. Proprietary vendor extensions that improve near-term functionality create extension-level fragmentation that procurement teams will inherit in multi-year contracts, often without understanding what they bought.

Vendor relationships complete the picture. The majority of API gateway vendors are expected to ship MCP-native features in the near term, meaning procurement decisions made now will embed MCP governance assumptions into multi-year contracts. Switching later means renegotiating not just tooling but the governance model those tools enforce.

Each of these looks like a configuration or vendor choice in the moment. Each functions as infrastructure after enough agents, servers, and compliance attestations are built on top of it.

What organizations that are getting ahead of this are doing differently

The organizations moving fastest in production agentic AI share one counterintuitive trait: they treated governance infrastructure as the precondition for speed, not the brake on it. The guardrails are what let them say yes to production deployments that teams without them are still debating in committee.

Central registry first is the single decision that most changes the downstream cost structure. Treating every MCP server as a governed identity before it reaches production, rather than after, creates a cost curve that scales linearly with growth. A registry retrofitted onto an existing estate scales with the size of the problem you deferred.

Gateway-layer enforcement is the second distinguishing choice. Pushing access controls, audit logging, and policy enforcement to the gateway rather than the application layer means policy changes propagate across the entire agent estate from one place. This is not primarily a security feature; it is what makes the governance model maintainable as the estate grows.

Real-time observability is a consistent requirement among organizations that have moved MCP deployments into production in a defensible way. Visibility into what an agent is touching in real time is the safety net that makes production deployment defensible to regulators and to internal risk functions simultaneously.

MCP Manager, built on Usercentrics' data governance platform, is one example of tooling designed around this architecture: a control layer that centralizes server registry, enforces role-based access control for agents, and provides real-time observability across the MCP estate.

Shadow AI grows where governed paths don't exist. Organizations that give teams a governed route to the MCP tools they want reduce ungoverned adoption far more effectively than those that restrict access and push the same behavior underground. The evidence on this is consistent across enterprise security contexts: restriction without substitution doesn't eliminate the behavior, it obscures it.

The AAIF's working groups on Identity and Trust, Security and Privacy, and Observability and Traceability are producing the spec-level answers to these problems. Organizations building governance infrastructure now that aligns with where those working groups are heading are making choices that will age well. Organizations waiting for the spec to finalize before acting are accumulating ungoverned exposure in the interim, and the interim has a cost.

Why the window for low-cost governance decisions is closing, not opening

The cost of retrofitting governance is not linear. It scales with the size of the installed base, the number of agents built on top of it, the compliance attestations written against it, and the vendor relationships contracted around it. Every one of those variables grows week by week.

MCP went from 12% to 28% Fortune 500 penetration in a single quarter. That is not the growth rate of a product in a competitive market. That is a protocol achieving critical mass. Organizations that have yet to formalize their MCP governance posture are not holding a stable position; they are watching the remediation cost increase in real time while describing that situation to themselves as patience.

The window for low-cost decisions is a function of installed base size, not organizational readiness. It closes on the market's schedule. The enterprises that will look back on this period as the moment they got ahead of the problem are the ones who recognized, early, that the first governance decisions were also the cheapest ones. Every week without a registry, without gateway-layer enforcement, without real-time observability, is a week in which the cost of eventually having those things goes up.

That tab is running whether or not anyone is watching it.

Sources

  1. guptadeepak.com

More in Features