Skip to content
Agentic Control Plane

What Is an MCP Control Plane?

An MCP control plane is the governance layer that sits between MCP clients (Claude Desktop, Cursor, Claude Code, custom apps) and the MCP servers they call. It verifies identity on every tool call, enforces policy, detects unsafe content, limits spend, and records a full audit trail — so MCP can be used in production on data that actually matters. It’s the specialization of the broader agentic control plane for Model Context Protocol deployments.

MCP CLIENTS where users work Claude Desktop desktop app · Cowork Cursor IDE · Composer agent Claude Code terminal CLI · hooks Cline · Codex CLI editor/CLI agents Custom clients MCP SDK apps MCP CONTROL PLANE every call inspected · governed · audited 🔑 Identity verification ⚖️ Policy evaluation 🛡️ Content safety 💰 Budget · rate limits 📋 Audit emission + delegation chain propagation MCP SERVERS where tools run Filesystem read/write local files GitHub issues · PRs · code Salesforce · Slack CRM · messaging Databases query · write · schema Custom MCP servers your internal tools
Every MCP call — from any client, to any server — passes through a consistent governance pipeline. No per-server or per-client reinvention.

The Short Version

Model Context Protocol (MCP) is great at what it does: expose tools from servers to AI clients in a standard shape. What MCP doesn’t solve — deliberately, by scope — is governance. The spec answers “how do I expose a tool?” It doesn’t answer:

  • Whose identity is attached to this call?
  • Is this user authorized to invoke this tool on this data?
  • Should the input or output be redacted for PII?
  • Has this user already exceeded their budget for the day?
  • Is this being logged in a way an auditor can use?

An MCP control plane is the dedicated layer that answers those questions for every MCP call in your environment, across every MCP server, consistently.

What Problems It Solves

Three production-AI failure modes that MCP alone doesn’t address:

1. Shared credentials flatten identity.

A typical MCP deployment runs the MCP server with a single service-account credential. Every user who invokes a tool through the MCP server hits the backend as that service account — the MCP client knows the real user, but the backend doesn’t. Classic Three-Party Problem in MCP clothing.

An MCP control plane propagates user identity through every call. Backends see which user initiated the request, not just “the MCP server did it.”

2. Tool permissions are per-server, not per-user.

Without a control plane, if an MCP server exposes ten tools, anyone connected to that server can invoke all ten. Per-user, per-tool, or per-agent scope restrictions either require the backend to re-enforce them (easy to forget) or don’t exist at all.

An MCP control plane applies scope narrowing at the proxy layer. The user’s role, the agent’s tier, and the specific tool are evaluated on every call — regardless of what the MCP server itself checks.

3. Audit evidence is usually missing or unstructured.

Most MCP servers log to stdout or to their own log file in whatever format the developer felt like writing. That’s unusable for SOC 2 evidence, HIPAA audit, or EU AI Act Article 14 compliance, all of which need unified, identity-attributed, queryable trails.

An MCP control plane emits structured audit records for every MCP call — tool name, input/output hashes, identity, policy decisions, cost — in one consistent schema regardless of which MCP server was called. See The MCP Audit Gap for the detailed problem statement.

Without a Control Plane vs With One

WITHOUT A CONTROL PLANE typical MCP deployment MCP client knows: user is Alice shared service acct MCP server sees: "service account" Problems ✗ identity flattens at the MCP boundary ✗ no per-user tool restrictions (all or nothing) ✗ no per-user budgets or rate limits ✗ PII / secrets cross boundary unchecked ✗ audit format varies per server, or missing ✗ compliance evidence is fragmented ✗ delegation chains absent for A2A flows WITH AN MCP CONTROL PLANE governed MCP deployment MCP client user: Alice CONTROL PLANE MCP server sees: Alice + context Unlocks ✓ user identity propagates to every server ✓ per-user, per-tool policy (3-axis ABAC) ✓ per-user budgets enforced before execution ✓ PII · secrets scanned at the boundary ✓ unified structured audit across all servers ✓ SOC 2 / HIPAA / EU AI Act evidence-ready ✓ delegation chains propagate through A2A
A control plane closes the seven governance gaps that MCP alone leaves open. Production-grade AI becomes possible.

What an MCP Control Plane Does

In concrete terms, an MCP control plane is a proxy or gateway that intercepts MCP traffic and runs a governance pipeline on every call. The pipeline typically includes:

  • Identity verification — JWT from the client is validated; user’s roles are resolved.
  • Server registration and scoping — which MCP servers are registered, which tools are exposed, who’s allowed to call what.
  • Policy evaluation — ABAC checks against user role, agent type, tool being called, and input/output content.
  • Content safety — PII detection, prompt injection scanning, secret redaction before data crosses trust boundaries.
  • Budget and rate limits — per-user, per-agent, per-tool spend caps enforced before execution.
  • Audit emission — structured log entries for every call (allowed, denied, or denied-for-safety).
  • Delegation chain propagation — when an MCP call is part of an agent-to-agent flow, the delegation chain rides alongside.

All of this happens at the MCP protocol boundary. MCP clients and MCP servers don’t need to know the control plane is there; they see a standard MCP connection with normal messages and tool responses. The difference is that unsafe or unauthorized calls never reach the server in the first place.

THE GOVERNANCE PIPELINE — PER-CALL every stage must pass before the call reaches the server · any failure = audited deny Tool call from MCP client name, input, JWT 1. IDENTITY verify JWT resolve roles bind chain context 2. POLICY 3-axis ABAC tool · agent · user most-restrictive wins 3. SAFETY PII scan secrets scan injection detection 4. BUDGET per-user cap per-agent cap rate limits 5. ROUTE select server SSRF guard mTLS outbound 6. EXECUTE MCP server call with Alice's ctx returns result 7. AUDIT — structured record emitted for every outcome (allow · deny · deny-safety) who · what · which server · which tool · which chain link · policy decisions · token counts · cost · timestamps SOC 2 / HIPAA / EU AI Act Article 14-ready — one schema, every call, every server
The seven-stage pipeline runs on every MCP call. Any stage can deny; every outcome is audited uniformly.

How It Relates to an MCP Gateway

“MCP gateway,” “MCP proxy,” and “MCP control plane” are overlapping but distinct concepts.

  MCP Gateway MCP Control Plane
Primary job Traffic management — discovery, routing, connection pooling Governance — identity, policy, audit, safety
Scope Data plane (execution) Control plane (authorization)
Examples Hosted MCP runtimes, MCP proxies ACP, dedicated governance layers
Usually includes SSRF protection, connection management Identity propagation, delegation chains, audit schema

Many MCP gateway products bundle a subset of control-plane features (the same way API gateways bundle authentication). The distinction matters when you need deep governance: you probably want both a gateway and a dedicated control plane, not one product trying to do everything.

See MCP Gateway Comparison for a concrete landscape view and the tradeoffs.

MCP Control Plane vs API Gateway vs LLM Gateway

These are commonly conflated. They operate at different boundaries and solve different problems.

Layer Operates at Governs
API gateway (Kong, Apigee) HTTP boundary Traditional REST traffic, rate limits, API keys
LLM gateway (Portkey, LiteLLM) LLM-call boundary Model routing, prompt caching, failover, basic safety
MCP control plane (ACP) MCP protocol boundary Identity, tool-level policy, content safety, delegation chains, audit

An API gateway doesn’t understand MCP’s tool shape. An LLM gateway doesn’t see tool calls once the model emits them — it sees the LLM response. The MCP control plane is the layer that understands MCP semantics specifically: tool names, input schemas, tool_use blocks, and the identity of the user behind the client. See Why API Gateways Don’t Solve AI Governance for the longer argument.

Deployment Patterns

Three common patterns for deploying an MCP control plane, in increasing depth of integration:

Pattern 1 — Registered as an MCP server in client config.

The simplest pattern: the control plane runs as an MCP server that clients register alongside (or instead of) their existing servers. Every tool call flows through it. Works with Claude Desktop, Cursor, Cline, and any MCP-compliant client. The control plane can expose a meta-tool interface that proxies to registered downstream MCP servers.

Pattern 2 — Client-side hook with control-plane backend.

For clients that support hooks (Claude Code, Codex CLI, Cursor), a local hook script POSTs every tool call to the control plane before execution. The control plane evaluates and returns allow/deny/transform, and the client enforces. See Claude Code integration for the canonical example.

Pattern 3 — Full proxy with delegation chain propagation.

For multi-agent deployments, the control plane sits as a full proxy in front of all MCP servers, propagating delegation chains across agent-to-agent calls. This is the deepest integration and the one that unlocks cross-agent governance.

When You Need an MCP Control Plane

If any of the following apply, a dedicated MCP control plane stops being optional:

  • You expose more than one MCP server and need consistent governance across them.
  • Your MCP server touches regulated data — PHI, PII, financial records, IP.
  • You have compliance obligations — SOC 2, HIPAA, EU AI Act Article 14, PCI DSS.
  • You need per-user or per-agent tool restrictions — not just per-server.
  • You have multi-agent workflows and need identity to propagate through delegation.
  • You need audit evidence for non-developer audiences — auditors, legal, security review.

Without a control plane, each of these pushes custom enforcement logic into each MCP server or each client — which is where governance erodes first in any fast-moving system. See MCP Security Checklist for Enterprise for the longer readiness checklist.

FAQ

Is an MCP control plane the same as an MCP gateway? No, but they overlap. An MCP gateway typically focuses on traffic management (discovery, routing, connection pooling). An MCP control plane focuses on governance (identity, policy, audit, safety). Many products bundle a subset of both; the distinction matters when you need deep governance.

Can I use MCP’s native authorization instead of a control plane? MCP’s native auth (bearer tokens, OAuth bridging) handles identification between client and server, but doesn’t handle user-level policy enforcement, cross-server consistency, audit emission, content safety, or delegation chains. A control plane layers these on top.

Does an MCP control plane replace an API gateway? No. An API gateway governs traditional HTTP traffic; an MCP control plane governs MCP-specific semantics. Most teams with significant AI deployments run both — the control plane sits in front of MCP traffic, the API gateway sits in front of non-MCP REST traffic.

Which MCP clients are compatible? Any MCP-compliant client. Claude Desktop, Cursor, Claude Code, Cline, Codex CLI, custom clients built on the MCP SDK — all work with a control plane registered as an MCP server or wired via hooks. See the integrations page for per-client install guides.

Is the MCP control plane relevant if I have only one MCP server? Less critical, but still useful for audit emission and identity propagation. The gap widens rapidly once you have more than one server or more than a handful of users — governance fragmentation compounds fast.

How does an MCP control plane relate to the Forrester Agent Control Plane category? The Forrester Agent Control Plane market evaluation covers the broader category. MCP-specific control planes are a sub-category — they specialize the governance primitives for the MCP protocol. A general-purpose agent control plane usually handles MCP alongside other transports.

Does an MCP control plane slow down tool calls? Typically 20–80ms added per call (identity check, policy evaluation, audit write — most of which is async). For interactive agents, imperceptible. For batch workflows running thousands of calls per minute, measurable but tunable via caching and fast-path policies.