From MCP Proof of Concept to Production Deployment

MCP pilots and production deployments are two different things, and most organizations confuse one for the other. A large share of technical leaders already report production use of MCP, the protocol Anthropic open-sourced in 2024, but only a small fraction of enterprise agentic AI pilots ever reach real production. The gap between those two numbers is not about the protocol being unready. It comes down to governance: the identity controls, audit trails, and access policies that a pilot skips and a production system cannot survive without.

Why MCP pilots stall before they reach production

Downloading MCP and running it is not the same as governing it, and that distinction explains almost every stalled pilot. A team spins up a community MCP server, connects it to a few internal systems, and shows it off in a demo. Nobody asks who owns the server, what data it can reach, or what happens if the credentials leak, because at that stage those questions feel premature.

The pattern repeats across companies in close to the same order. Someone installs a server without checking who built it or what it touches. Permissions get set wide open, because the team wants to see what the tool can do before narrowing anything down. Security review gets pushed to "later," since the project is still "just a prototype." Then, weeks later, the prototype is quietly running against production data, with real users depending on it, and no governance structure was ever put in place to catch that transition.

That sequencing error, scaling access before the governance infrastructure exists to support it, is the central failure mode behind stalled MCP projects. Not a secondary issue, not a rough edge to smooth out later. It is the mechanism that turns a working demo into a frozen initiative, because by the time anyone notices the gap, the system is already load-bearing and too risky to touch without a plan. Everything that follows in this piece addresses that one sequencing problem, piece by piece, in the order it needs to be solved.

What a PoC environment tolerates that production cannot

A proof of concept survives on conditions that production quietly refuses to accept. Four gaps in particular appear in nearly every PoC, and each one turns into either a blocker or a breach vector the moment real usage begins.

The first is authentication built on static secrets. The 2026 MCP roadmap names static client secrets as a known problem in current deployments, and it's easy to see why they persist: an API key dropped into an environment variable works immediately, with no setup overhead. But a credential that never expires and never rotates is a standing liability once more than a handful of people depend on it.

The second gap is the absence of an audit trail. MCP doesn't currently define a standard way to surface audit information, so teams end up building their own logging from scratch and piecing together request chains after something goes wrong. That's tolerable in a prototype nobody is auditing. It falls apart the moment a compliance review or an incident response team asks a straightforward question: what did this agent actually do, and when?

The third is undefined behavior at the gateway or proxy layer. The protocol stays silent on what happens when a request passes through an intermediary: how authorization claims carry forward, how session state gets handled, what a gateway is even allowed to look at. A PoC usually connects client to server directly, so it never runs into this. Production almost always needs an intermediary somewhere in the path. This silent gap becomes an open question right when the stakes are highest.

The fourth is configuration that doesn't travel. MCP server settings, tool permissions, connection parameters, access scopes, are typically tied to one specific client. For a single developer, resetting that configuration when switching tools is a minor annoyance. For an enterprise rolling the same server out to dozens of developers across multiple client applications, it becomes a deployment blocker on its own.

Put these four together and a PoC that "works" is handing teams false confidence. None of the conditions that actually define production, concurrent users, compliance review, incident response, credential rotation, have been tested. The demo proved the idea. It proved nothing about whether the system can be trusted at scale.

The attack surface that governance neglect creates

An ungoverned MCP deployment is an active attack surface, and the incidents behind that claim already have names attached.

Start with the blast radius problem, because it connects directly to the credential gaps described above. MCP servers often sit in front of several enterprise systems at once, and they hold the credentials for all of them behind a single interface. Compromise that one server and the damage isn't contained to a single integration. It spreads across every system that server touches and every agent or user that depends on it. A single point of failure now controls an entire credential graph, not just one key.

OWASP's MCP Top 10 project has already catalogued the attack classes security teams test against today. Tool poisoning hides malicious instructions inside tool metadata, with schema poisoning and tool shadowing as specific variants of the same trick. Command injection exploits agent input that was never sanitized. Shadow MCP servers run outside any formal governance process, so the teams who should be tracking them never see them. Context over-sharing leaks information across agent sessions that were supposed to stay separate. None of these are theoretical categories. They're the checklist security teams run against real deployments right now.

Regulation has caught up to the same risk. The EU AI Act's high-risk obligations under Annex III become enforceable on December 2, 2027, after a Digital Omnibus regulation pushed the date back from the original August 2, 2026 deadline. MCP gateways handling regulated data fall inside that scope, so audit logging of every agent action is now a legal requirement, not just a nice-to-have. An attack surface discovered after a breach was never a surprise. It existed from the moment the server went live without governance attached to it, waiting for someone to find it.

The July 2026 Spec Revision's Governance Obligations

The 2026-07-28 specification revision fixes real problems at the protocol level, but it also makes a deliberate choice: push more of the security responsibility onto the teams operating MCP servers. Read the revision as handing operators more work, not less.

At the protocol level, the fix is substantial. MCP moves from a stateful, session-based model to a stateless request/response design. The initialize/initialized handshake is gone. The Mcp-Session-Id header is gone. Every request now carries its own protocol version, client identity, and capabilities with it. Practically, that means any server instance can handle any request behind a plain round-robin load balancer, which resolves the horizontal scaling complaint that's dogged MCP deployments since early adoption.

Authorization tightens at the same time. The core authorization spec now tracks closer to how production OAuth 2.0 and OpenID Connect systems already work: issuer validation gets added, client credentials bind to their specific authorization server, and Dynamic Client Registration gets deprecated in favor of Client ID Metadata Documents.

None of that makes the July revision a governance solution on its own. It's a prerequisite improvement, the groundwork that makes governance possible, not the governance itself. The 2026 MCP roadmap says as much directly: most enterprise readiness work is expected to land as extensions built on top of the spec, not as changes to the core protocol, because loading enterprise requirements into the base spec would make the protocol heavier for every team using it, including the ones that don't need those controls. A team that upgrades to the July 28 spec and then sits back waiting for the protocol itself to start enforcing access policy and audit logging will be waiting a long time, because that responsibility was just handed to them.

Building the server registry as the first governance control

Every control described from here forward, access policy, audit logging, incident response, depends on one prior step: knowing every MCP server the organization actually runs.

The logic is straightforward. Any server added without a registry entry is an identity nobody is tracking. An identity nobody is tracking is the one that eventually gets exploited; OWASP's MCP threat list names shadow servers as their own category of risk, not an edge case.

Pinterest offers a concrete working model here. The company runs domain-specific MCP servers for its data platforms, covering Presto, Spark, and Airflow, alongside a general-purpose knowledge server, all tracked through a central registry built for server discovery. Before any of those servers reaches production, it has to pass Security review, Legal/Privacy review, and, where relevant, GenAI compliance review, since the registry is a gate nothing passes through unreviewed.

A registry worth the name captures the server's identity, the team that owns it, the systems it connects to, the credentials it holds, its approved set of tools, and the date of its last security review. A registry missing any of those fields is a list, not a control that does anything.

The 2026 roadmap's transport work makes this easier to maintain going forward. It defines a standard metadata format served via .well-known, so you can discover server capabilities without a live connection to check them. A registry can stay populated and auditable even for servers that aren't currently active, and teams building registries now should design around that capability.

This is precisely the sequencing error named at the start of this piece, playing out in reverse when done right. Scaling MCP access before the governance infrastructure exists is the failure mode. Centralized governance platforms exist specifically to stop that sequence by establishing access-control policy, identity management, and audit logging before access scales out, which is what actually separates a governed production deployment from a PoC that got lucky. Get the registry right, and the organization can answer "what does our AI actually have access to?" in minutes. Without it, that question has no answer.

Replacing static credentials with identity-aware authentication

The static API key described earlier as a PoC shortcut is also the single most exploitable gap in most MCP deployments, and closing it means moving to credentials that are scoped, rotating, and tied to a real identity system rather than sitting in an environment variable indefinitely.

The 2026 roadmap describes the target as "paved paths" away from static secrets and toward SSO-integrated flows, pointing specifically at Cross-App Access: access brokered through the organization's existing identity layer, where SSO goes in, scoped tokens come out, and IT stays in the loop the entire time. The real test of whether this is working is simple: can the enterprise approve an MCP deployment without carving out a special exception to its existing security policy? If the answer is no, the architecture isn't finished.

Cloudflare's approach shows what this looks like in practice. MCP servers are deployed remotely on Cloudflare's developer platform and managed centrally. Authentication runs through Cloudflare Access, which ties into SSO, supports MFA (though it isn't enforced for portal-authorized servers), and factors in contextual signals like IP address, location, and device certificates. A unified MCP server portal lets users discover and reach authorized servers in one place, and administrators can enforce DLP rules and control which tools are exposed to which users.

The July 28 spec revision's shift toward OAuth 2.0 and OIDC issuer validation, along with Client ID Metadata Documents, makes this kind of OAuth-based authentication easier to build, not harder. Teams that invest in it now are building with the direction the protocol is already heading, not against it.

Role-based access control for AI agents makes sure that whatever an agent can do reflects a decision someone actually made, rather than a permission set that accumulated by accident across a dozen rounds of PoC iteration. Credential scope matters as much as credential type here: a short-lived OAuth token scoped to one server's specific tool set keeps a compromise contained to that server alone. A static, broadly scoped PoC-era key does the opposite, propagating risk across the entire credential graph it was ever granted access to. The absence of an enforcement point for that scoping, a gateway that can actually check authorization claims and propagate them correctly across intermediaries, is itself one of the PoC gaps named earlier. A centralized MCP governance layer handles policy enforcement at that point in the architecture, without requiring every client and every server to solve the same problem independently.

Making agent actions visible in real time through audit logging and observability

Reading an audit log after an incident is a postmortem. It tells a team what already happened, after the damage is done. Production and regulatory compliance both require something different: visibility into what an agent is touching while it's touching it, not a reconstruction built after the fact from scattered logs.

This is the third structural gap carried over from the PoC stage, and it's the one regulators now check for directly. Under the EU AI Act's Annex III obligations, enforceable December 2, 2027, audit logging of agent actions on regulated data is a legal requirement for any MCP gateway inside that scope, not a feature a team can decide to skip. A compliance reviewer asking "what did this agent do with this data, and when" needs an answer that exists before the question gets asked, not one assembled afterward from fragments of custom logging that happened to survive.

Real-time observability turns an MCP deployment from a liability waiting to surface into a system that can actually be defended under review. Visibility into agent actions as they happen lets a security team catch tool poisoning, command injection, or a shadow server before it does damage, rather than relying on a record read after an incident. That's the operational safety net that separates a governed production deployment from a prototype that happened to stay online long enough to become load-bearing.