MCP Is the Data Plane. You Still Need a Control Plane.
A developer spins up an MCP server, connects it to Claude Desktop, and within ten minutes an AI agent is querying their production CRM. The tool call works. JSON-RPC request goes out, structured response comes back. Clean, fast, exactly what MCP was designed for.
Nobody asked who the user behind that request was. Nobody checked whether this agent was allowed to access customer data. Nobody logged which records were returned, to whom, or why. The tool call succeeded. The governance didn’t exist.
This is the gap that will define the next wave of AI security incidents — and it stems from a fundamental architectural confusion: treating MCP as a control plane when it is, by design, a data plane.
The misidentification
A growing number of posts and talks describe MCP as “the control plane of agentic AI.” The framing is understandable — MCP is the most widely adopted standard in the space — but it’s architecturally imprecise.
MCP is a protocol. It defines JSON-RPC methods for tool discovery (tools/list), tool invocation (tools/call), and structured responses. It specifies how an LLM discovers available tools, how it formats a call, and how the server returns results. This is data plane work — the mechanics of moving a request from point A to point B and getting a result back.
The MCP specification is explicit about what it does not cover. The spec says tools are “model-controlled” — the LLM decides what to call, when, and with what arguments. There is no identity verification in the protocol. No authorization policy language. No audit log schema. No rate limiting. No PII detection. No budget controls. No tenant isolation.
This isn’t a criticism of MCP. It’s MCP doing exactly what a data plane should do: handling the how of tool invocation without entangling the whether. The problem starts when teams deploy MCP in production and assume the protocol handles governance. It doesn’t. It was never designed to.
The networking analogy you already know
If you’ve built or operated network infrastructure, the data plane / control plane split is second nature.
Data plane = packet forwarding. A switch receives a packet on one port and sends it out another. It doesn’t decide routing policy. It doesn’t authenticate the sender. It moves bytes according to rules it was given.
Control plane = routing decisions, access control lists, policy enforcement. The control plane decides which packets are allowed, where they should go, and what to do when something violates policy. BGP, OSPF, firewall rules, NAT policies — all control plane.
The same separation exists in Kubernetes. The kubelet runs containers (data plane). The API server enforces admission control, RBAC, and resource quotas (control plane). In service meshes, Envoy proxies handle traffic (data plane) while Istio enforces mTLS, authorization policies, and observability (control plane).
Nobody would run a production network with a data plane and no control plane. Packets would flow, but with no routing policy, no access control, no audit trail. It would be fast, functional, and completely ungoverned.
That’s exactly what happens when you run MCP servers in production without a governance layer.
What MCP does
Credit where it’s due. MCP solves a real problem, and it solves it well.
Before MCP, every agent framework invented its own tool-calling convention. LangChain had one format. AutoGen had another. Custom integrations used whatever JSON the developer felt like that day. MCP standardized the interface: here’s how you describe a tool, here’s how you call it, here’s how you return results.
Concretely, MCP handles:
- Tool discovery —
tools/listreturns available tools with their input schemas - Tool invocation —
tools/callsends a structured request to the server - Response formatting — structured content types (text, image, resource) come back in a predictable shape
- Transport — stdio for local, SSE/HTTP for remote, with a clean abstraction layer
This is genuinely useful infrastructure. It’s the USB-C of agent tool calling — a standard interface that means you write the integration once and it works across clients.
But USB-C doesn’t authenticate the device plugged into the port. It doesn’t decide whether that device is allowed to transfer data. It doesn’t log what was transferred. USB-C moves data. Security policy lives elsewhere.
MCP moves tool calls. Security policy needs to live elsewhere too.
What MCP does not do
The absence of governance in MCP is not an oversight. It’s a design boundary. But the consequences of ignoring that boundary in production are already visible.
No identity verification. When an MCP tool call arrives at your server, the protocol carries no verifiable claim about who initiated the request. Your backend sees a JSON-RPC method call. It doesn’t see a JWT. It doesn’t see a user sub. It sees a tool name and arguments. The three-party problem — user, agent, backend — collapses into a single anonymous call.
No authorization policy. MCP has no concept of “this user is allowed to call this tool but not that one.” Every tool listed in tools/list is available to every connected client. There’s no scope restriction, no role-based filtering, no deny-by-default posture. If the tool exists, the agent can call it.
No audit logging. MCP defines no log format, no audit schema, no mechanism for recording who called what, when, why, or what was returned. If your compliance team asks “show me every AI-mediated access to customer data in Q1, attributed to specific employees,” MCP has no answer.
No PII detection. Data flows through MCP tool calls in both directions — arguments going to the server, results coming back to the model. Neither direction is inspected for sensitive content. Social security numbers, credit card data, medical records — they pass through the protocol without scrutiny.
No rate limiting or budget controls. An agent stuck in a retry loop can hammer an MCP server indefinitely. There’s no per-user rate limit, no cost tracking, no circuit breaker. A single misconfigured agent can burn through your entire monthly budget before anyone notices.
No tenant isolation. In multi-tenant deployments, MCP provides no mechanism for ensuring that Tenant A’s agent cannot access Tenant B’s tools or data. Isolation is left entirely to the implementer.
The evidence is already in
This isn’t a theoretical concern. The consequences of running MCP without governance are already documented.
Trend Micro’s early 2026 scan found 492 exposed MCP servers with zero authentication. Not weak authentication. Zero. These servers accepted any JSON-RPC call from any source and executed it against live backends — databases, APIs, internal services. Every one of them was a data plane operating without a control plane.
The first confirmed malicious MCP server — a package called postmark-mcp — silently BCC’d every outgoing email to an attacker-controlled address. The tool discovery interface showed a clean email-sending tool. The implementation added a hidden recipient on every call. Without identity-attributed audit logging, affected users had no way to know which messages were compromised, for how long, or which accounts were exposed.
The Snyk audit of ClawHub found that 12% of published skills were compromised — including a campaign delivering macOS malware through markdown injection in tool descriptions. These tools passed MCP’s discovery interface perfectly. They listed clean schemas and helpful descriptions. The malicious behavior lived in the execution layer, where MCP has no inspection mechanism.
These aren’t edge cases. They’re the predictable result of deploying a data plane protocol without control plane governance. A network without access control lists gets probed. An API without authentication gets abused. An MCP server without identity, policy, and audit gets exploited. The pattern is as old as networked computing.
What the control plane adds
The agentic control plane sits between the MCP client and your backend. It doesn’t replace MCP — it governs the requests MCP carries. Every tool call passes through the control plane before reaching your server, and every response passes back through before reaching the model.
Seven capabilities define the control plane layer:
1. Identity binding. Every request is cryptographically tied to the originating user. Not a service account. Not a shared API key. A verified JWT carrying the user’s sub, scopes, and tenant context, validated against your IdP’s JWKS endpoint on every call. Full explanation in AI Agent Identity: The Problem No One Has Solved Yet.
2. Policy enforcement. Deny-by-default. An agent starts with zero permissions and receives only the tool scopes explicitly granted. Policies are declarative, version-controlled, and enforced at the gateway — not inside the agent’s prompt, where the LLM can ignore them.
3. Scope restriction. Agent permissions are always a strict subset of the delegating user’s permissions. The intern’s agent and the CFO’s agent get different capabilities, automatically, because they inherit different scopes. An autonomous process running at machine speed should never hold the same privilege level as the human it acts for.
4. Audit logging. Identity-attributed record of every tool call: who initiated it, which policy rule allowed or denied it, what data was involved, what it cost. Not service_account: POST /api 200. Real attribution: user:auth0|8f3a2b1c called tool:crm:read:contacts, policy:rep:allow:crm:read, 47ms, $0.003.
5. PII detection. Content inspection on both request arguments and response payloads. Social security numbers, credit card data, email addresses — detected and redacted before they reach the model or leave your perimeter.
6. Budget controls. Per-user, per-agent, per-tenant spending limits. Estimated cost tracked per call, cumulative spend tracked per window. An agent that exceeds its daily budget gets a policy denial, not an invoice surprise.
7. Tenant isolation. Multi-tenant separation at the control plane. Tenant A’s agents see Tenant A’s tools. Tenant B’s policies apply to Tenant B’s agents. Isolation is enforced architecturally, not by convention.
The request flow
Here’s what an MCP tool call looks like with a control plane in the path:
User → LLM → MCP Client → Control Plane → MCP Server → Backend
↓
Identity ✓ (JWT verified)
Policy ✓ (deny-by-default)
Scope ✓ (agent ⊂ user)
PII scan ✓ (redacted)
Budget ✓ (within limit)
Audit ✓ (logged)
The MCP protocol carries the tool call. The control plane governs whether it proceeds. Neither does the other’s job. Both are required for production.
In code:
// Without control plane: MCP tool call goes straight to backend.
// Backend sees: anonymous JSON-RPC. No identity. No policy.
// With control plane: MCP tool call hits the gateway first.
const decision = await controlPlane.evaluate({
identity: req.user, // JWT-verified: "auth0|8f3a2b1c"
tool: "crm:read:contacts",
tenant: "acme-corp",
policy: tenantPolicy,
});
// decision.allowed → true
// decision.reason → "policy:rep:allow:crm:read"
// decision.logged → audit trail written with full attribution
// decision.piiScan → "no PII detected in request arguments"
The control plane doesn’t know or care whether the tool call arrived via MCP, a custom REST integration, or a webhook. It operates at the trust boundary. Swap MCP for another protocol and governance follows automatically — because it’s enforced at the boundary, not inside the data plane.
Why the confusion matters
Calling MCP a control plane isn’t just a semantic error. It creates a false sense of security.
When a team believes their data plane protocol handles governance, they don’t build governance infrastructure. They deploy MCP servers, point agents at them, and assume the protocol covers identity, authorization, and audit. It doesn’t. The gap between what they believe is covered and what actually is covered becomes the attack surface.
This is the same mistake teams made in the early days of REST APIs. “We have HTTPS, so we’re secure.” TLS encrypts the transport (data plane). It doesn’t authenticate the user, authorize the request, or log the action (control plane). Teams that confused transport security with application security shipped APIs that were encrypted but ungoverned. The AI agent ecosystem is making the same mistake one layer up.
The CSA’s framework for the Agentic Control Plane identifies this governance layer as architecturally distinct from the execution layer. The OWASP Top 10 for Agentic AI traces its top attack categories to the absence of exactly this infrastructure. The analysis converges: MCP is necessary but not sufficient. The data plane needs a control plane.
Where to start
If you’re running MCP servers today — or planning to — ask three questions:
-
Identity. Does your backend know which human user initiated each MCP tool call? If your server sees anonymous JSON-RPC or a shared service account, you have the gap. Start with identity binding.
-
Authorization. Are tool permissions enforced at the infrastructure level, or does every tool in
tools/listaccept calls from every connected client? If there’s no deny-by-default policy, every tool is an open door. Understand runtime authorization. -
Audit. Can you produce an identity-attributed record of every MCP tool call in the last 30 days, showing who called what, which policy allowed it, and whether PII was involved? If your logs show
tool_call: crm:read 200with no user attribution, you can’t satisfy SOC 2 or HIPAA. See what compliance-ready audit looks like.
GatewayStack is one implementation of the Agentic Control Plane pattern — the governance layer that sits on top of MCP (or any tool-calling protocol) and adds the identity, policy, and audit infrastructure the data plane was never designed to provide. Open source. MIT licensed. Incrementally adoptable alongside your existing MCP servers.
Get started free · Reference architecture · Data plane vs control plane
MCP is good infrastructure. It’s the wrong layer for governance. Build both planes.