What MCP Governance Actually Means in Production

At the protocol level, MCP governance refers to how the Model Context Protocol is managed as an open standard. But that’s not the governance problem most teams are actually dealing with. The real issues show up in how MCP behaves in production.

Once the MCP is deployed, it becomes a runtime layer that lets agents call tools, access data, and take action across your systems. At that point, governance is about control and visibility – which MCP servers are allowed, how credentials are issued and scoped, what data can be accessed or written, and whether every action can be traced back to a user.

Without clear controls, an MCP in production quickly turns into an unmonitored access layer. But don’t worry, this post tackles this problem. It’ll break down how to run MCP safely in real systems and prevent it from becoming an unmonitored access layer into your infrastructure.

Why an ungoverned MCP is a production liability

The risks around MCP come from how easily it can be used without guardrails:

• Shadow MCP: Developers can connect agents to MCP servers in minutes, often without going through any review process. That means agents may be calling tools from unvetted servers that IT and security teams don’t even know exist. Preventing this starts with restricting which servers can be used at all, not just trusting developers to choose correctly.
• Credential exposure: Most MCP integrations still rely on insecure patterns. Around 53% use static API keys, only 8.5% use OAuth, and 79% store credentials in environment variables. MCP itself originally shipped without built-in authentication, and while OAuth support was added in March 2025, it’s still optional. The result is predictable: shared tokens, weak rotation, and no clear mapping between actions and users.
• Supply chain risk: The postmark-mcp rugpull incident is a good example – an unofficial package impersonated the Postmark name and was distributed as a legitimate integration. This shows how easily trust can be abused in the MCP ecosystem.

Across all three, the risk compounds. A compromised MCP server exposes itself and inherits the agent’s permissions, making it a direct path to internal data and systems.

Four governance primitives every MCP deployment needs

Most risks trace back to MCP being decentralized by design – there’s no single place enforcing control. Each server defines its own tools, authentication, and behavior. Without a unifying layer, governance ends up fragmented across every integration, which doesn’t scale.

A workable approach is to standardize around the following four core primitives:

An MCP gateway like Portkey enforces all four from a single control point. Instead of enforcing controls per server, the gateway becomes a single control point that sits between agents and MCP servers. It applies registry checks, handles authentication, enforces runtime policies, and captures logs consistently across all traffic.

Which servers are allowed to run?

Controlling MCP starts with one basic question: which servers are your agents allowed to connect to at all?

That’s the role of a trusted registry. Instead of letting agents discover and connect to any MCP server, you maintain an allowlist of approved ones. A proper registry entry should include the server’s identity, a version pin (ideally with a SHA-256 hash), the tools it exposes, the owner, and its approval status. This turns “any server” into “only reviewed and verified servers.”

The complexity comes from how MCP works. Servers can add or modify tools over time, and agents will automatically pick those up. This is the dynamic tool discovery problem. Without controls, a previously approved server can introduce new capabilities – like write actions or data access – without review. A governance-aware registry solves this by blocking unapproved tools and triggering a review before they become available.

It’s also important to be clear about public registries. The official MCP registry does not perform security vetting – it typically verifies ownership of a repo or domain, not whether the server is safe to use. Treat it as a discovery layer, not a trust layer. A better reference is JSON-schema–based registries used in major cloud platforms, where structure and validation are enforced.

The real challenge is adoption. The governed path has to be the easiest path, or developers will route around it. Portkey’s MCP Gateway implements this as a centralized registry with enforcement gating, so only approved servers and tools are reachable by agents.

Who can access what, and how do credentials work?

In many setups, agents connect to MCP servers using shared API keys or long-lived tokens. That works for a quick demo, but it doesn’t hold up in production. Shared credentials are indistinguishable in logs, which means you can’t tell which user triggered an action. Rotation becomes operationally painful as usage scales. And if a single token is exposed, it effectively grants access to everything that token can reach.

The alternative is per-user authentication, typically using OAuth 2.1. Instead of agents authenticating as a generic service, they act on behalf of an actual user. Every request carries user identity, scoped permissions, and an expiration window. That immediately improves traceability, limits blast radius, and makes revocation practical.

In a production setup, this usually ties into your existing identity provider via SSO, using SAML or OIDC. That way, MCP access inherits the same identity controls, group mappings, and policies you already enforce across your organization. Authentication stops being something you bolt onto MCP and becomes part of your broader access model.

The gateway layer is what makes this workable. Rather than each MCP server handling authentication differently, the gateway centralizes it. It manages OAuth flows, validates JWTs, and ensures that every request to an MCP server is authenticated, scoped, and attributable to a user. 

Portkey’s MCP Gateway, for example, supports OAuth 2.1, JWT validation, and direct integration with enterprise Identity Providers (IdP) to enforce this consistently across all servers.

Runtime enforcement and data protection

Authentication answers who a user is. Governance also needs to answer what they’re allowed to do and what data is allowed to move via the following layers:

• First layer – tool-level RBAC: MCP permissions can’t stop at the server level because a single server may expose dozens of tools, including read and write operations. Access needs to be defined at the tool level – who can call which tool, under what conditions, and in which context. Portkey enforces tool-level RBAC per organization, workspace, team, and user, so access isn’t overly broad by default. Portkey adds another layer of protection against misuse or anomalous behavior by providing runtime threat detection through its partnership with Lasso.
• Second layer – PII redaction and data controls: Sensitive data should be filtered at the gateway before it ever reaches an MCP server, or before responses are returned to the agent. This ensures that even trusted tools don’t receive or expose data they shouldn’t.
• Third layer – human-in-the-loop controls for high-risk actions: Actions like writing to production systems, triggering payments, or modifying records can be routed for approval before execution. This introduces friction where it matters, without slowing down low-risk interactions.

Together, these controls turn MCP from an open execution layer into a governed one where access is scoped, data is protected, and high-impact actions are deliberate.

Audit trails and regulatory compliance

If MCP is an execution layer, then audit logs are your only reliable record of what actually happened.

A production-ready MCP audit trail needs to capture more than basic request logs. At a minimum, every interaction should include user identity, timestamp, session ID, prompt, tool name, parameters, server identity, response, and any data sources accessed. The goal is non-repudiation – you need to be able to prove which agent called which tool, on behalf of which human, and what the outcome was.

This is where MCP governance connects directly to compliance frameworks like NIST AI Risk Management Framework and ISO/IEC 27001:2022. The primitives discussed earlier map cleanly to existing controls:

There’s a common misconception here. Frameworks like NIST AI RMF and ISO 42001 are often cited for “AI governance,” but they primarily focus on model-level risks – bias, explainability, and lifecycle management. They don’t fully address agent systems that can take action through tools, which is where MCP operates.

That gap is exactly why detailed audit trails matter. Without them, MCP becomes a blind spot from both a security and compliance perspective.

Portkey addresses this by logging every MCP interaction end-to-end, with enterprise-grade controls backed by SOC 2 Type II, ISO 27001, HIPAA, and GDPR compliance.

Building your governance stack

As you can probably tell, MCP governance needs to be built in from the start. The implementation sequence is straightforward: start with a trusted registry to control which servers can run, add centralized authentication to tie every action to a user, enforce runtime policies to control what agents can do, and finish with audit logging to make every action traceable.

The challenge is stitching these together without fragmentation.

Portkey’s MCP Gateway provides all four layers in a single control point. It’s open source, self-hostable, and designed to enforce governance without slowing teams down.

Explore Portkey’s MCP Gateway today and see how the full stack works in practice!

FAQ

Which platforms offer managed solutions for MCP governance?

There are three main categories:

• Purpose-built MCP gateways are designed specifically to control MCP traffic and enforce governance primitives. 
• API gateway platforms that have been extended to support MCP patterns. 
• Integration platforms that add governance layers on top of agent workflows. 

Portkey’s MCP Gateway is an example of a purpose-built approach, while Microsoft has published an open-source reference architecture that shows how similar controls can be implemented.

Why is an MCP gateway recommended for AI agents?

An MCP gateway provides a single enforcement point for all governance primitives – registry control, authentication, runtime policy enforcement, and audit logging. Without it, these controls have to be implemented separately across each MCP server, which quickly becomes inconsistent and unmanageable. Centralizing enforcement is what makes MCP governance scalable.