MCP has an integration story. It has an adoption story. It does not have a governance story. That is the gap everyone keeps skating past, and it is turning into the main problem of mid-2026.

Ninety-seven million SDK downloads a month. Twenty-eight percent of the Fortune 500 using it. Enterprise-Managed Authorization shipped stable on July 6, with Anthropic, Microsoft, and Okta behind it. Sounds like a done deal. But only about 5 percent of MCP servers actually run in production. The rest sit on developer laptops. “We integrated MCP” and “we govern MCP at scale” are two very different sentences, and most enterprises are stuck between them.

Enterprise Auth Finally Has an Answer

For most of MCP’s life, auth has been the loudest production blocker. Each server handled its own OAuth 2.1 flow. Users clicked through consent prompts one server at a time. Token lifecycles didn’t match long-running agent sessions. Personal and work accounts bled together in ways that made compliance teams nervous.

The Enterprise-Managed Authorization extension fixes the consent problem. Instead of per-server, per-user approval, the auth decision moves to the org’s identity provider. Admins set policy once. Users sign in once and get access to every approved MCP server.

Under the hood, it uses an Identity Assertion JWT Authorization Grant (ID-JAG), exchanged for access tokens by each server’s authorization server. Identity policy stays separate from tool execution. The enterprise layer controls who connects and at what scope, but once the token is issued, it doesn’t inspect MCP traffic.

Client support is already broad: Claude, Claude Code, Cowork, VS Code. Server support too: Asana, Atlassian, Canva, Figma, Granola, Linear, Supabase, with Slack in progress. Okta is the first identity provider with a production path through its Cross App Access approach.

But EMA solves connection-level auth. It doesn’t solve runtime authorization for individual agent actions. Once an agent is inside a system, what it does next is still your problem.

The Security Side of the Equation

While the auth side improved, the security picture got worse. UberConf 2026 opened in Denver this week with 40-plus speakers. Agent security was the dominant theme, and the data they brought was not reassuring.

Veracode tested the latest flagship models across five critical vulnerability categories in Java code. Security pass rates: roughly 55 percent. Nearly identical to two years ago. Java performed worst, probably because models over-trained on legacy patterns from public repos that predate modern security frameworks. Without explicit security-focused prompting, half of AI-generated Java code contains exploitable vulnerabilities. The models are getting better at everything except writing safe code.

Spring AI made it worse. The framework reached production readiness in 2025 and became the default for enterprise Java teams building with LLMs. Then in April 2026, community-submitted security advisories spiked 1,700 percent over historical averages. Broadcom responded with the largest set of Spring security updates in the framework’s 23-year history. The disclosed vulnerabilities included SQL injection through Spring AI vector store interfaces and expression language injection in RAG pipelines that enabled remote code execution.

The MCP spec is also catching up to its own scale gaps. Version 2026-07-28, due in ten days, transitions to a stateless protocol core. Current MCP servers must maintain session state, which forces sticky routing and limits horizontal scaling. The new spec standardizes session creation, resumption, and migration so server restarts and scale-out events are transparent to clients. It also adds TTL-based cache control for resource reads and W3C Trace Context propagation for distributed tracing through tool call chains.

Where the Gap Lives

The protocol layer keeps improving. The governance layer has not caught up. That is the pattern.

Integration works. A Java developer can add an MCP server connection the same way they add any other Spring dependency. Auth has an answer now. EMA gives enterprises centralized access control through their existing identity provider.

Everything between “connected” and “governed” is still missing.

Runtime authorization is the obvious one. EMA controls who connects, not what an agent does once it’s in. Per-action policy enforcement is your problem. Blast radius management is the scarier one. If an agent misbehaves or an MCP server gets compromised, what contains the damage? Most deployments don’t have an answer.

Audit trails are getting closer. The new spec adds trace context propagation, which helps. But producing an auditable log of every agent decision, tool call, and outcome across an MCP deployment is still beyond most organizations. And then there’s the servers themselves. With 95 percent of MCP servers running on developer machines rather than hardened production environments, the surface area for supply chain and configuration vulnerabilities is large and nobody is watching most of it.

What Comes Next

The best framing came from UberConf itself: agents should earn autonomy, not start with it. The GOAP (Goal-Oriented Action Planning) architecture presented at the conference requires agents to satisfy explicit preconditions before executing any action and maintain typed invariants throughout execution. That is the governance pattern MCP needs at the protocol level. It doesn’t have it yet.

If you’re evaluating MCP for production right now, the short version: deploy EMA if your identity provider supports it (Okta is live, others coming). Move your MCP servers off developer laptops and treat them like any other service endpoint. Build your own runtime controls for per-action authorization, especially for write operations and anything touching sensitive data. And keep an eye on the July 28 spec release, because the stateless core and trace context changes will affect how you architect MCP at scale.

MCP solved the integration problem. It’s solving the auth problem. The governance problem is next, and for now, each org is on its own.