Your Team Deployed MCP. You Still Don't Have a Governance Framework

Ninety-seven million SDK downloads. Ten thousand public MCP servers. Every major enterprise software vendor either building MCP support or announcing it. By most measures, the Model Context Protocol has already won the integration standard debate — and teams are deploying fast.

But 53% of MCP servers in production still use long-lived static secrets for authentication. API keys. Personal access tokens. Credentials that don't expire, don't scope to specific actions, and don't tell you which agent used them or when. Only 8.5% use OAuth. The rest are betting that the server won't get hit, the key won't leak, and nobody will ask for an audit trail.

That's not an authentication problem. It's a governance problem wearing an authentication costume.

MCP solves a real engineering challenge. Before a universal protocol existed, connecting an AI agent to ten different tools meant ten different integrations — each custom-built, each maintained separately, each requiring its own error-handling and version management. The engineering simplification is genuine and significant. It's also what makes the governance gap dangerous.

When each integration was custom-built, the scope of what an agent could access was constrained by what got built. Connecting an agent to your CRM meant writing code that called specific CRM endpoints. The agent could do what the code allowed. Nothing more. That constraint was a side effect of the architecture, not a governance decision — but it functioned as one. MCP removes that side-effect constraint. An agent connected through MCP can discover and invoke tools it wasn't explicitly programmed to use, within whatever permissions the MCP server grants. The scope of access is now determined by runtime context and server configuration, not by what a developer hard-coded six months ago.

When we built data classification infrastructure at Box, the hardest part wasn't the technical architecture. It was answering questions we hadn't thought to ask before the system was running: Who authorized this access? What was it used for? If the classification produced a wrong outcome, could we show how it happened? Those questions don't get easier when the system is an autonomous agent with dynamic tool access. They get harder.

The governance failure mode I keep seeing in MCP deployments isn't malicious. It's structural. Teams treat MCP as an integration decision and stop there. They configure the server, connect the agent, test the workflows, ship it. The integration works. The governance questions — authorization scope, audit logging, access controls, what happens when the agent takes an action it wasn't supposed to — get deferred to a second phase that rarely arrives. Those questions don't disappear when you defer them. They accumulate.

The EU AI Act provides a useful frame for what's at stake. Article 14 requires "meaningful ability to intervene or override agentic transactions" — but provides no technical guidance on how to achieve that dynamically, at runtime, across tools the agent discovers autonomously. The UK Information Commissioner's Office has been direct that organizations remain responsible for data protection compliance of every AI system they deploy, including agentic ones. They didn't add an exception for systems using open protocols. Meanwhile, 40% of early agentic AI deployments fail before reaching production scale. The post-mortems consistently identify the same culprits: governance gaps, unclear decision authority, inadequate logging. Not capability failures. Operating model failures. MCP can accelerate getting agents into production. It does nothing about the operating model they land in.

The vendor contract dimension is where in-house counsel often first encounters this problem — usually after the fact. Most enterprise software agreements were drafted assuming human-driven API calls: predictable volume, defined use cases, a person or team as the accountable party for how the API gets used. MCP changes the access pattern. An agent connected through MCP can discover and invoke capabilities dynamically, potentially accessing data or triggering workflows that weren't contemplated in the original contract scope. When the vendor's ToS restricts "automated access" or limits use to "your organization's employees," it's genuinely unclear whether an autonomous agent operating under a shared credential satisfies that definition. The agent isn't in HR's system. There's no individual identity attached to its actions. The authorization trail exists only if someone built it. Review your top vendor agreements with this question: Does this contract address what an autonomous agent can access, at what volume, with what logging requirements, and with what liability allocation if it errs? Most don't. Most were written before that question was obvious.

None of this means MCP is the wrong choice. The integration simplification it delivers is real, and the alternative — custom-built integrations for every tool, every vendor, every use case — doesn't scale and doesn't get audited any better in practice. The point isn't to avoid MCP. It's to be clear about what MCP does and doesn't provide. It gives agents a standard interface for connecting to tools. It doesn't define what agents are authorized to do with those connections, specify logging requirements, allocate liability when an agent acts outside expected scope, or ensure your vendor contracts cover the new access pattern. Those are governance decisions that require human choices about authorization, oversight, and accountability — and they need to be made before the agent starts running.

The organizations that get this right won't have better MCP implementations. They'll have built the governance layer alongside the integration layer, rather than planning to add it later. Governance architecture added after deployment is almost always insufficient — it's designed around what you thought the system would do, not what it's actually doing. The window to make those decisions thoughtfully is before the agents are in production. That's where in-house counsel should be: in the architecture conversation, not the incident response.