MCP Is in Production. Governance Isn't.

Your engineering team is already running MCP servers in production. Forty-one percent of surveyed software organizations are, according to Stacklok's 2026 State of MCP in Software report. The protocol ships with no built-in framework for security policy, authorization, or auditability. The Cloud Security Alliance flagged this gap for enterprise CISOs on June 15, cataloguing seven risk categories introduced by MCP adoption across development pipelines and operational systems.

None of this is a reason to slow down MCP adoption. It is a reason to govern at the right layer.

The structural problem

MCP is a communication protocol. It connects AI agents to tools, data, and services. It is good at that and not designed to be a policy enforcement system. When you deploy an MCP server and point Claude Code or another AI assistant at it, the agent can read context, generate code, write to filesystems, and call APIs. What happens to that output, and whether it conforms to your security and compliance policies, is not the protocol's job.

This is not a bug. It is a scope decision. The risk gap exists because teams are scaling MCP deployments before governance architecture catches up to them. The result is AI-generated code that reaches commits and production without policy verification at the layer where it was actually produced.

Where governance belongs in an MCP workflow

The correction is not to add a post-commit scanner and call it done. Code that reaches a scanner already represents developer time, review cycles, and potentially a deployment gate. The earlier you catch a policy violation, the cheaper it is to fix.

In an MCP-integrated workflow, "earlier" means the moment the agent is instructed. When Claude Code or another AI assistant calls an MCP server to generate code, that request is the intervention point. Policy can be injected at the MCP layer, before generation, so the AI produces code that conforms to your policies from the start rather than code that gets kicked back later.

This is not a theoretical architecture. MCP policy injection is the first layer in a graduated enforcement stack: inject policy at generation (MCP) then catch anything missed in the IDE, at the pre-commit hook, and at the PR gate. Each layer earlier in the pipeline is cheaper and faster than the layer after it.

What this means for teams already running MCP in production

If your team has MCP servers in active use, the governance question is not whether to impose controls but where to impose them. Three concrete steps:

First, audit what your MCP servers can do. Content injection, over-privileged agents, and supply chain exposure (all named in the CSA paper) are a function of what the agent can access, not just what it generates. Scope your MCP permissions to what AI workflows actually need.

Second, decide whether generated code is verified before it reaches a commit. If your only check is a PR review, you are relying on a human to catch policy violations that a deterministic rule could have prevented at generation time.

Third, map your compliance templates to the MCP layer. If you have SOC 2 or ISO 27001 controls that govern code, those controls should be active when AI writes that code, not when a human reviews it.

MergeGuide closes this gap at the MCP layer: policy is injected when the agent generates code, so your AI writes code that conforms to your governance requirements from the first token, not after the fact.

Forty-one percent of software organizations are already in production with MCP. The governance decision is not whether to adopt controls, but whether to place them at the agent layer now or spend the next two years patching downstream.