Control Plane vs Data Plane Architecture in Enterprise AI Infrastructure

A unified MCP control plane lets platform engineering teams share identity, permissions, policy, and audit across AI projects without having to rebuild the security plumbing for each one. The data plane connects agents to tools and executes their actions. In enterprise AI infrastructure, separating these responsibilities is the foundation for making agents both capable and governable.

How network engineering's control/data plane split maps onto enterprise AI infrastructure

In network engineering, the control plane governs routing decisions, while the data plane moves traffic. In enterprise AI, the same division separates decisions about what an agent may do from the machinery that carries out its actions. The data plane runs tasks, invokes tools, queries systems, and executes business processes. The control plane enforces per-user identity, tool-level permissions, and policy, then produces the audit trail needed to govern that activity.

The Model Context Protocol (MCP), open-sourced by Anthropic in late 2024, gives agents a standard way to connect to tools and systems in the data plane. But a common connection protocol does not itself supply a common authority over those connections. An agent can have a working path to a tool without having properly governed permission to use it. The planes are therefore distinct but interdependent, with one providing capability and the other setting its boundaries.

What the data plane actually does when an AI agent takes an action

Data-plane execution includes tool invocation, file access, API calls, database queries, code execution, and cross-agent communication. MCP organizes these operations through a server/client model that exposes external systems through a standardized interface. Those systems include file systems, databases, SaaS APIs, and code repositories. The interface makes different tools accessible through a common protocol, but each tool still reaches a backend with its own data and permissions.

MCP defines two primary transport mechanisms, namely Streamable HTTP for remote server connections and STDIO, or standard input/output, for local integrations. STDIO requires no network infrastructure and is the most widely deployed path. A single MCP session can connect an agent to dozens of servers simultaneously, including file system, GitHub, Slack, Stripe, and database connectors. As a result, one agent action can propagate across many backend systems. MCP servers also often hold credentials for several enterprise systems behind a single interface, bringing both access and risk into one place.

Why an ungoverned data plane becomes a liability rather than an asset

Without a control plane, that concentration creates three compounding problems, which are an authentication vacuum, credential sprawl, and an expanding blast radius. The Cloud Security Alliance’s MCP Security Crisis note describes an OAuth 2.1 authorization framework that says authorization is optional, which leaves servers exposed without authentication. Trend Micro found 492 unauthenticated servers in a July 2025 scan.

Credential sprawl follows when each agent or connector authenticates independently, without a central identity layer. Raw API keys and copied session tokens pile up without per-session scoping, a single revocation point, or a unified audit trail to keep track of them. A compromised server can then affect every backend it touches. Cross-server tool shadowing widens that exposure because a malicious server can inject tool descriptions that redirect the agent’s understanding of adjacent trusted tools. These are the threats addressed by security layers such as Runlayer’s, which combine per-session credential scoping, policy enforcement at tool invocation, real-time MCP attack detection, and tamper-proof audit logs.

What the attack surface looks like when the planes are not separated in practice

OX Security’s April–May 2026 research, “The Mother of All AI Supply Chains,” identified a command execution vulnerability in Anthropic’s official MCP SDKs for Python, TypeScript, Java, and Rust, with estimated exposure of roughly 200,000 vulnerable instances. The STDIO transport passed parameters straight to the host OS shell without sanitization, so a process command could run whether or not it initialized a valid MCP server. Wiz Research’s June 2026 disclosure described CVE-2026-12957 in the Amazon Q VS Code extension, which enabled arbitrary code execution and cloud credential theft through a crafted workspace MCP configuration file. Spawned server processes inherited the full developer environment, so an attack that worked could reach past the tool configuration into cloud infrastructure.

The April 2026 Azure MCP Server Information Disclosure vulnerability, CVE-2026-32211, allowed access to configuration details, API keys, and authentication tokens without valid credentials. Researchers examining the ClawHub Marketplace in February 2026 identified malicious skills delivering the Atomic macOS Stealer to developers who installed them. Because there was no verification layer between publication and installation, a marketplace entry gave attackers a way into the developer’s environment. The shared pattern is a control-plane gap expressing itself as a data-plane compromise.

What the control plane must govern to close those gaps

The control plane must bind every action to a verified identity tied to a specific agent, user, and context, rather than accept a session token as a complete account of authority. NIST’s agent identity concept paper identifies four focus areas, namely identification, authorization, access delegation, and auditing/logging. In practice, each agent and integration needs a distinct identity, while tokens must be scoped to the intended resource and validated for audience. The control plane must also maintain a registry mapping every MCP server and tool to an owner, version, data classification, permission set, approval rule, and kill switch. Server upgrades and tool-list changes need security review because they change what the agent can reach or run.

Policy must apply to each agent, task, and tool, even after broad permissions have been granted during provisioning. Irreversible or high-risk actions need human approval before the data plane executes them, and unapproved dynamic tool additions must be blocked. Tamper-proof audit records must capture server identity, tool definition version, caller, user, scopes, arguments, result, and approval status. Structured telemetry must flow from the data plane into the control plane in real time. That gives alerting the context needed to flag new servers, expanded scopes, unusual call volume, sensitive data access, and failed authorization.

How the MCP authorization specification has evolved to support control-plane integration

The MCP 2026-07-28 specification, whose release candidate was published May 21, 2026, spells out more of how control-plane integration works. It removes sessions, drops the initialization handshake, hardens authorization, and introduces an extensions framework. MCP servers are formally OAuth 2.1 resource servers and MUST implement OAuth 2.0 Protected Resource Metadata (RFC 9728), allowing clients to discover the correct authorization server automatically. There are separate authorization paths for clients that act for users through OAuth 2.1 and PKCE, unattended agents that act for themselves, and enterprise-managed access through an identity provider. Resource-bound tokens and per-request authorization give the control plane set points at which to enforce access.

Identity products supply parts of that architecture. Microsoft Agent 365, generally available May 1, 2026, builds on Microsoft Entra Agent ID, generally available April 2026, with integration into Conditional Access and Microsoft Purview. Auth0’s “Auth for MCP” became generally available May 6, 2026, while Okta’s MCP server uses scope-based tool loading to expose tools according to OAuth scopes and authenticated user privileges. These capabilities support enterprise authorization, but the protocol still cannot prove which agent or runtime holds a token. The control plane still needs verifiable workload identity, so protocol support allows integration but leaves part of the governance system unfinished.

Why governance and production readiness depend on the control plane being in place before the data plane scales

The gap between downloading MCP software and running it in governed production is an operating problem. A pilot can demonstrate that an agent reaches a tool without establishing who owns that access, how it is revoked, or what evidence survives an incident. Before production, the enterprise must have answers to those questions that it can enforce. Otherwise, each new workflow adds dependencies before the enterprise has a reliable way to control them. Pressure from regulators also calls for the enterprise to account for how access is used, beyond making sure it works.

Forrester formally recognized the “agent control plane” as an emerging market category in December 2025. Its definition covers an enterprise control plane that inventories, governs, orchestrates, and assures heterogeneous AI agents across vendors and domains. The incident record also undercuts the claim that governance can safely wait until after adoption. Controls are harder to enforce and audit when they are added after scale, and waiting leaves time for attacks of the kind already seen.

How do platform teams centralize MCP governance across many AI teams, and where does Runlayer fit?

Enterprises can assemble a control plane from discrete components, including an agent builder, a gateway, a security tool, and an identity layer. They can also adopt a platform that integrates these responsibilities by design. When the control plane is built from separate components, it has to keep identity context, audit records, and policy state intact as they pass between those components. A platform that brings these parts together must meet those same requirements, even if it has a single interface. A unified MCP control plane means shared, enforceable governance across teams.

Runlayer implements the control/data plane separation as a core architectural principle, with an AI control plane enforcing identity, permissions, and policy at tool-call depth and an MCP gateway connecting agents to a broad ecosystem of integrations. Its enablement layer includes built-in OAuth and credential handling, plus agent setup from Slack. Its control layer covers MCPs, skills, and agents, tying identity to actions through SSO, SCIM, and JIT credentials. Its security layer adds detection for tool poisoning, prompt injection, intent drift, and exfiltration, backed by tamper-proof audit logs and full OTEL tracing.

Session-level identity and audit, as implemented in unified platforms including Runlayer, make it possible to detect and block MCP-specific patterns before they propagate across backend systems. Those patterns include tool poisoning, intent drift, and cross-server credential reuse. Here, session-level governance covers what agents do and the scope of their credentials, without requiring protocol sessions to be kept. The practical value is a shared access path that does not require every AI team to duplicate security plumbing. When that path includes the controls from the start, the easiest approved way to use agents can also be the governed one.

The practical starting point for enterprises separating their control and data planes today

Start by making an inventory of the data plane before giving agents more access. Scan for exposed MCP endpoints, query for /mcp and /sse paths, and check for 0.0.0.0 bindings. A map of each workflow includes its MCP servers, the credentials those servers hold, and the backend systems they touch. Treat server counts and download figures as adoption-intent signals. That map establishes where controls must apply and which dependencies a change could affect.

Next, establish identity before granting access. Give each agent and integration a distinct identity, validate token audience, and scope every token to its intended resource. Separate development, testing, and production credentials from the start. Then create an MCP register with an owner, version, data classification, permission set, approval rule, and kill switch for every server and tool. Require review for tool-list changes and server upgrades, block unapproved dynamic additions, and pin and verify package versions and hashes.

Finally, build in detection and rollback because failures can still happen after approval. Log tool discovery, inputs, outputs, identity, approval, and result for every tool call. Alert on new servers, expanded scopes, unusual call volume, sensitive data access, and failed authorization. Keep a way to quickly disable any server or tool while leaving unrelated workflows running. Security teams that put these boundaries in place before broad deployment make company-wide AI adoption possible.