Your MCP server governance plan: A step-by-step guide

Developers building AI agents move fast. When a new tool needs to be connected, the quickest path is to spin up an MCP server, wire it to an agent, and ship. Multiply that pattern across dozens of teams and you end up with something that looks less like a governed AI platform and more like a sprawling web of unmanaged connections to your most sensitive systems.

This is the shadow MCP problem. It is not theoretical. It is already happening in organizations that have adopted agent-based AI without a formal governance plan in place.

This guide gives developers, platform engineers, and security architects a clear, practical roadmap for implementing MCP server governance from scratch. It is organized as a sequential set of steps, so you can deliver value at each stage rather than waiting until everything is perfect before you start.

What MCP governance actually means

Before getting into the how, it’s worth being precise about the distinction between security and governance, and how both apply differently to MCP compared to traditional APIs. These are related but distinct concepts, and conflating them is the most common source of confusion when organizations start thinking about MCP risk.

API security vs MCP security

API security protects the transport and authentication layer. It answers the question: Is this request coming from a legitimate, authenticated client? Controls like OAuth 2.1, TLS, rate limiting, and IP allowlisting live here.

MCP security addresses the same question but must go further because the protocol introduces threats that traditional API security was not designed to handle:

• Tool poisoning: A malicious or compromised MCP server can serve corrupted tool definitions to agents, embedding hidden instructions in a tool name, description, or schema to manipulate agent behavior before any tool is ever executed.
• Credential isolation: In a multi-tool environment, tokens passed to one MCP server must not be visible to or reusable by others.
• Primitive-level access control: Access must be enforced at the level of individual tools, resources, and prompts, not just at the server or endpoint level.

Traditional API security mechanisms carry over to MCP but are insufficient on their own. The attack surface is different because the protocol is different.

API governance vs MCP governance

API governance manages the lifecycle and operational behavior of APIs at scale. It covers registration, versioning, deprecation, usage policies, and SLA enforcement. The API gateway is the enforcement mechanism, where the policies defined by governance are applied at runtime.

MCP governance works the same way. It manages the lifecycle and operational behavior of MCP servers and the agents that consume them. The MCP gateway is the enforcement mechanism, where the policies defined by MCP governance are applied at runtime. Just as an ungoverned API creates shadow integrations, an ungoverned MCP server creates shadow MCPs.

MCP governance specifically covers two areas that have no direct equivalent in traditional API governance:

MCP server lifecycle management

• Registration: Every MCP server must be registered in a central inventory before it can receive agent traffic.
• Vetting and approval: New servers go through a defined review process before being added to the allowlist.
• Policy assignment: Each registered server is assigned governance policies defining which agents can access which tools, resources, and prompts.
• Monitoring: Active servers are continuously monitored for anomalous behavior and policy violations.
• Deprecation and retirement: Servers are formally decommissioned through a managed process rather than quietly abandoned, preventing hidden dependencies from breaking agent workflows.

Agent behavior governance

Should this authenticated agent be allowed to perform this specific action, on this specific tool, in this specific context, right now? Are there high-risk operations that require human approval before execution? Is there an immutable audit trail of every action every agent has taken?

The core distinction between API governance and MCP governance is that API governance manages APIs and their lifecycle. MCP governance manages both MCP servers and their lifecycle and the behavior of the agents operating within them. An agent operating under a valid token can still cause serious damage if governance controls are not in place. Authentication confirms identity. Governance manages behavior.

MCP security and MCP governance are complementary, not interchangeable. Security is a prerequisite; without it, governance has no foundation. Governance is what makes agent-based AI safe to operate in production at scale.

Why ungoverned MCP servers are a serious risk

The risks of shadow MCPs are concrete and material:

• Unauthorized actions: An improperly configured agent with write access to a production system can modify, delete, or corrupt data based on a misinterpreted instruction. Unlike a human operator, the agent will not pause to question whether the action seems unusual.
• Data exposure: Internal tools connected via MCP can return sensitive data, such as PII from a CRM or financial records from an ERP, which gets passed into an LLM context window without any masking or redaction policy in place.
• Compliance violations: Without a governed framework controlling what data agents can access and what actions they can take, it becomes very difficult to demonstrate compliance with regulatory requirements such as GDPR, HIPAA, and CCPA.
• Operational instability: Shadow MCPs create hidden dependencies. When an unregistered server goes down or is updated without coordination, workflows that have quietly come to depend on it break without warning.

The foundation: Understanding what you are governing

An MCP server exposes three types of primitives to AI agents. Your governance plan needs to address all three.

• Tools are the functions an agent can undertake, such as creating a ticket, querying a database, or sending an email. Governing tools means controlling which agents can see and invoke them, and under what conditions.
• Resources are the data sources an agent can read or write. Governing resources means enforcing context minimization, ensuring agents only receive the data they actually need for a specific task.
• Prompts are the pre-defined prompt templates an MCP server exposes to agents. Governing prompts means controlling which agents can access which templates and ensuring their integrity before they reach the agent.

This is the layer at which MCP governance operates. It is distinct from API security, which has no awareness of these primitives at all.

Step 1: Discover and inventory your MCP footprint

You cannot govern what you cannot see. The first step is building a complete picture of every MCP server running in your environment.

How to find them

Start by scanning your network for endpoints communicating using the MCP protocol. Search your code repositories for MCP server libraries, configuration files, and deployment scripts. Talk to engineering teams directly, as developers often know about servers that have never been formally registered anywhere.

What to record for each server

For every server you find, capture at minimum: 

• The owning team and individual
• The tools it exposes with their names and descriptions
• The resources and data schemas it can access
• Whether it is running in production or development

Assign a risk level

Not all servers carry the same risk. A simple classification is enough to start:

The output of this step is a registry: A single authoritative inventory of your entire MCP footprint. Everything that follows depends on it. As your AI environment matures, this registry should become part of your broader AI control stack, a central system of record that is accessible by both humans and machines. Platform teams use it to enforce governance policies. Automated systems use it to validate that every agent request is destined for a known, approved server. Treating the registry as infrastructure from the start, rather than a spreadsheet or a one-time audit, is what makes governance scalable.

Step 2: Establish a central control point

With your registry established as the authoritative source of truth for your MCP environment, the next step is connecting it to a runtime enforcement mechanism. The registry tells you what should exist and what should be permitted. The MCP gateway is what enforces those decisions on every live agent request.

Why is a traditional API gateway not sufficient here? Because an API gateway enforces policy at the HTTP and transport layer. It can authenticate a request and apply rate limiting, but it can’t see inside the MCP protocol. It has no awareness of which tool is being called, which agent is calling it, or what permissions should apply at the tool level. Most traditional API gateways also lack native support for streaming protocols like Server-Sent Events and WebSockets, which are required for MCP agent interactions. AI agents executing multi-step tasks maintain persistent, long-running connections rather than making short stateless requests. A gateway that cannot handle streaming cannot reliably proxy MCP traffic.

An MCP gateway enforces policy at the tool and agent semantic layer. It parses the JSON-RPC body of every request to understand exactly what is happening, enabling capabilities that a generic HTTP proxy can’t provide:

• Filtered tool discovery: The gateway intercepts the tools/list response and returns only the tools a specific agent is permitted to see. An agent that can’t call a tool doesn’t know the tool exists.
• Per-tool access control: Access policies are enforced at the individual tool level, not just at the server level.
• Per-tool rate limiting: Independent rate limit counters per named tool per agent, rather than a single blanket limit across all traffic.
• MCP server allowlisting: Only servers registered in your inventory from Step 1 are accessible. Any request to an unknown server is blocked and logged immediately.

What to do in this step

• Deploy an MCP gateway as the mandatory entry point for all agent-to-tool traffic. 
• Update your network rules to ensure all MCP requests flow through it. 
• Configure it to route only to servers in your registry. 
• Enforce authentication at the gateway level using short-lived tokens with narrowly scoped permissions. 
• Enable centralized logging of every tool invocation, capturing agent identity, tool name, request parameters, response code, and latency.

This eliminates shadow MCP access and gives you the visibility you need to govern effectively.

Step 3: Define and enforce governance policies

With a gateway controlling traffic and your MCP server inventory in place, the next step is defining the rules that govern what each agent is permitted to do. This is where governance moves beyond authentication into behavioral control.

Policies are the core mechanism

Rather than configuring access rules on each MCP server individually, a well-designed MCP gateway uses a centralized policy model. A policy defines the access rights, rate limits, and tool-level permissions for a class of agent. Once a policy is defined, keys or tokens are issued to agents that inherit those rules. The gateway enforces the policy on every request automatically.

This approach means you define governance once and issue as many agent credentials as you need. When an agent is decommissioned or compromised, you revoke its credentials in one place. The upstream MCP servers don’t need to change.

Start with these foundational policies

Tool scoping by agent role: Not all agents should have access to the same tools. A reporting agent should be able to call read-only data tools but not write or delete operations. Define separate policies for each agent role, such as reader, analyst, or admin, each explicitly listing the tools that role is permitted to invoke. Any tool not on the list is invisible to that agent entirely. This is filtered discovery: An agent that can’t call a tool doesn’t know the tool exists.

Per-tool rate limiting: Different tools carry very different cost and risk profiles. A tool that queries a data warehouse is not equivalent to a tool that returns a static lookup. Define rate limits at the individual tool level rather than applying a single blanket limit across everything. This protects expensive or sensitive operations from being exhausted by an agent running in a loop, while leaving unrelated tools unaffected.

Quota controls: Beyond per-minute rate limits, define hard usage quotas over longer periods for tools where volume has cost or compliance implications.

Keep policies simple and narrowly scoped

Every governance rule should have a clear purpose tied to a specific risk. Policies that try to account for every possible edge case become difficult to maintain and audit. Start with three to five rules that address your highest-priority risks, typically tool scoping by role, rate limiting on expensive operations, and credential isolation across servers. Add complexity only when a specific operational need demands it.

A note on policy-as-code tools

Tools like Open Policy Agent are sometimes discussed in the context of API governance. It is worth understanding clearly which layer these tools operate at. In some gateway implementations, OPA is used to govern access to the management dashboard itself, controlling what administrators can do when configuring and managing APIs, rather than for evaluating runtime tool call requests. Runtime policy enforcement for MCP traffic is handled natively by the gateway’s own policy engine. Make sure you understand this distinction when evaluating governance tooling so you’re not assuming coverage that doesn’t exist at the runtime layer.

Step 4: Add human oversight for high-risk actions

Some agent actions should never be fully automated regardless of how well the policy engine is configured. Destructive operations, large financial transactions, or actions affecting regulated data are candidates for human approval before execution.

How to implement it

Update your policies to place high-risk requests in a pending state rather than simply allowing or denying them. Configure your gateway or policy engine to trigger a notification to a human approver via Slack, Microsoft Teams, or a ticketing system like Jira or ServiceNow, containing the full context of what the agent is trying to do and why.

The approver reviews the request and either approves or denies it. Approval sends a signal back to the governance platform, which releases the request. Denial terminates it with a clear response to the agent.

This human-in-the-loop layer is the final safety net for the operations where the consequences of a mistake are severe enough that automated governance alone is not sufficient.

Step 5: Treat governance as an ongoing program

Governance is not a project with an end date. It is an ongoing operational discipline that needs to evolve as your AI environment grows.

What ongoing governance looks like in practice

Establish a clear owner for the governance framework, typically a central platform or security team. Define a formal process for registering new MCP servers before they go to production. Review your risk classifications and policies on a regular cadence, at minimum quarterly. Monitor for anomalies in agent behavior such as unusual tool call frequency or access patterns that deviate from baseline.

Critically, make the governed path the easiest path for developers. Provide clear documentation, self-service registration workflows, and fast actionable feedback when a request is denied. A governance framework that developers find painful to work with will be worked around, recreating the shadow MCP problem you set out to solve.

Choosing your tooling

Any effective MCP governance implementation requires four components working together:

• MCP gateway: The single entry point for all agent-to-tool traffic. Choose a purpose-built MCP gateway or an API management platform with verified native MCP support. The key requirement is that it understands MCP protocol semantics natively, not just HTTP.
• Policy engine: The mechanism by which governance rules are defined and enforced. In most MCP gateways, this is handled natively by the gateway itself. Understand whether your chosen gateway enforces policies at runtime in the request path or only at configuration time. This distinction has significant implications for your governance posture.
• Identity provider: The system of record for agent and human identities. This manages credentials and integrates with OAuth 2.1 for token issuance and revocation.
• Audit store: A secure, tamper-proof logging system capable of handling high-volume ingestion. Every tool invocation should flow here for compliance and incident response purposes.

Three mistakes that undermine governance programs

Starting with policies that are too complex: The temptation when writing policy-as-code for the first time is to account for every edge case. Resist it. Complex policies are slow, hard to debug, and hard to maintain. Start with three to five simple, high-impact rules and build from there.

Ignoring the developer experience: Developers will bypass governance that’s opaque, slow, and manual. Make registration self-service, provide clear feedback when requests are denied, and document your policies so developers understand why rules exist, not just what they are.

Treating it as a one-time project: The AI agent landscape is evolving rapidly. New servers, new tools, and new attack techniques emerge constantly. Your governance framework needs an owner, a review cadence, and a process for change. Without these, it will quietly and quickly become outdated while your risk exposure grows.

Frequently asked questions

What is the difference between MCP governance and API security?

API security operates at the transport and authentication layer, confirming that a request comes from a legitimate authenticated client. MCP governance operates at the tool and agent semantic layer, managing what an authenticated agent is permitted to do in context. You need both, but they answer different questions and require different controls.

Do I need a purpose-built MCP gateway or can I extend my existing API gateway?

For basic authentication and logging, an existing API gateway can provide a starting point. However the moment you need filtered tool discovery, per-tool access control, or tool-level rate limiting, you need a gateway that understands the MCP protocol natively. A generic HTTP proxy is blind to tool-level semantics and cannot provide those capabilities, regardless of how it’s configured.

Can OPA govern both my MCP traffic and my existing APIs?

Yes, and this is one of OPA’s key advantages. Because it’s a general-purpose policy engine that evaluates any JSON input, the same OPA instance and the same Rego policies can govern MCP tool calls, REST API requests, and GraphQL queries from a single place. This reduces the operational overhead of maintaining separate policy frameworks for different traffic types.

Who should own the MCP governance framework?

Ownership should be centralized with a platform engineering or security team who own the gateway, policy engine, and registry. Individual development teams are responsible for registering their MCP servers within that framework and collaborating on the policies that apply to their tools. Shared responsibility with centralized ownership is the right model.

How do I handle credentials for tools connected to an MCP server?

Credentials should never be stored in code or configuration files. MCP servers should retrieve credentials from a dedicated secrets management system such as HashiCorp Vault or AWS Secrets Manager at the moment they’re needed, and discard them immediately after use. This prevents long-lived credentials from accumulating in environment variables or configuration files where they become an attack surface.

Conclusion

MCP creates a powerful capability by connecting AI agents directly to your tools and data. Without a structured governance approach, that connectivity becomes a liability rather than an asset.

The good news is that governance doesn’t require doing everything at once. Starting with discovery and a central control point delivers immediate, meaningful risk reduction. Adding policy enforcement and human oversight on top of that foundation builds toward a mature posture incrementally, without blocking development teams from moving forward.

The organizations that will use agentic AI most effectively are those that treat governance not as a constraint on development but as the infrastructure that makes reliable, production-grade AI possible.

Ready to establish your central control point? Talk to the Tyk team about how Tyk MCP Gateway can help you implement your governance plan today.