What Is an MCP Control Plane?
The Model Context Protocol (MCP) gives LLMs a standard way to discover and call tools. It’s a good protocol. It solves the integration problem — how do you connect an AI model to your CRM, your database, your internal APIs?
What MCP doesn’t solve is the governance problem. Who is calling this tool? Are they allowed to? Is sensitive data leaking into the prompt? Is anyone keeping a record?
An MCP control plane is the governance layer that answers those questions for every MCP tool call.
The gap in MCP
MCP defines how a client (the LLM) discovers tools on a server and how it invokes them. The protocol handles serialization, transport, and capability negotiation. It works well for what it does.
But MCP has no built-in concept of user identity. When Claude calls an MCP tool on your server, the server receives the tool name and parameters. It doesn’t receive a verified identity for the human who typed the prompt. The server can’t distinguish between your CEO and a summer intern — both look like the same MCP client.
This means MCP servers today operate with:
- No per-user access control — every user gets the same tool access
- No identity-attributed audit trails — you know a tool was called, but not by whom
- No PII detection — sensitive data in prompts flows through unchecked
- No per-user rate limiting — one user’s runaway loop affects everyone
These aren’t protocol bugs. MCP is a tool integration protocol, not a governance framework. But production deployments need both.
What an MCP control plane does
An MCP control plane sits between MCP clients and your MCP servers. It intercepts every tool call and runs it through a governance pipeline before the call reaches your server.
The pipeline handles five concerns:
- Identity — verifies the user’s JWT against your identity provider (Auth0, Okta, Entra ID) and binds the request to a real person
- Policy — checks whether this specific user has permission to call this specific tool, deny-by-default
- Content safety — scans tool parameters for PII (SSNs, credit cards, emails) and redacts or blocks before the data reaches your server or the model
- Usage limits — enforces per-user rate limits and budget caps to prevent runaway agent loops
- Audit — logs every tool call with the verified user identity, the policy decision, and the outcome
The MCP client doesn’t need to change. The MCP server doesn’t need to change. The control plane operates transparently at the boundary.
Implementation
Here’s what adding a control plane to an MCP server looks like with GatewayStack:
import { identifiabl } from "@gatewaystack/identifiabl";
import { validatabl } from "@gatewaystack/validatabl";
import { transformabl } from "@gatewaystack/transformabl";
import { limitabl } from "@gatewaystack/limitabl";
import { explicablLoggingMiddleware, createConsoleLogger } from "@gatewaystack/explicabl";
// Governance pipeline — runs before every MCP tool call
app.use(identifiabl({
issuer: process.env.OAUTH_ISSUER!,
audience: process.env.OAUTH_AUDIENCE!,
}));
app.use("/tools", transformabl({ blockThreshold: 80 }));
app.use("/tools", validatabl({ requiredPermissions: ["tool:read"] }));
app.use("/tools", limitabl({
rateLimit: { windowMs: 60_000, maxRequests: 100 },
budget: { maxSpend: 500, periodMs: 86_400_000 },
}));
app.use(explicablLoggingMiddleware(createConsoleLogger()));
Five modules. Each handles one governance concern. Every MCP tool call passes through the full pipeline — identity verified, policy checked, content scanned, limits enforced, action logged.
The same pattern works whether you’re running one MCP server or fifty. The governance is consistent across all of them because it’s enforced at the control plane layer, not reimplemented in each server.
MCP control plane vs MCP server
An MCP server exposes capabilities — tools the model can call. It handles the “what can the AI do?” question.
An MCP control plane governs those capabilities — who can use them, under what conditions, with what safeguards. It handles the “should this user be allowed to do it?” question.
You need both. The server without a control plane is an ungoverned tool. The control plane without servers has nothing to govern. They’re complementary layers that serve different purposes.
Why this matters now
MCP adoption is accelerating. Claude, ChatGPT, Cursor, and dozens of other clients support the protocol. Teams are publishing MCP servers for everything — databases, CRMs, code repositories, internal tools.
But most MCP servers today are deployed with a shared API key and no user-level governance. This is the same pattern that fails in production for every agentic system: no identity binding, no per-user policies, no audit trail.
As MCP moves from developer tools to production enterprise deployments, the governance gap becomes a blocker. Compliance teams won’t approve an MCP server that can’t attribute actions to individual users. Security teams won’t sign off on tool access with no policy enforcement. The control plane is how you close that gap.
Get started → · Reference architecture → · Pricing →