Control Plane vs. Data Plane Architecture in Multi-Agent AI Systems

Permission-aware multi-agent orchestration for large enterprises requires a control plane that governs identity, policy, and audit separately from the data plane that executes tasks. To respect each user’s row-level permissions throughout a multi-step pipeline, authorization must be evaluated for every action. The architectural test is whether governance follows the full agent chain, regardless of which model, tool, or team performs the work.

Why multi-agent AI systems need a structural separation between governing and executing

Agents can do more than ever, but the infrastructure to control them has not kept pace. Governance built for single-turn chat does not cover autonomous systems taking several actions across several services. Data access is fragmented, authentication differs between tools, and no unified audit trail connects the steps.

The Model Context Protocol, or MCP, made this tension concrete by giving agents a common way to connect to enterprise systems. Connection alone is not permission to act. When the same layer must execute calls and decide what is permissible, each new agent or team adds another place where policy can diverge. That calls for a structural boundary beyond what another rule in a tool’s configuration can do.

What the data plane actually does — tool calls, context retrieval, and task execution

The data plane performs the agent’s work. MCP gives that work three forms, namely Resources, Tools, and Prompts. Resources provide passive reads of file contents, database records, or configuration state. Tools execute actions such as API calls, database writes, and workflow triggers, while Prompts provide reusable, parameter-driven templates that guide repeatable behavior. These primitives describe what an agent can use.

MCP runs over JSON-RPC 2.0. The Host, which is the AI application, creates isolated Client sessions, each maintaining a stateful channel with its own Server. That server is LLM-agnostic, so a compliant client can use it without changing its code. Transport determines where execution lives. With stdio, servers run as local processes suited to developer tooling, while Streamable HTTP supports independent network services behind load balancers, with OAuth 2.1 authentication. Neither a callable tool nor an authenticated connection, however, establishes whether a particular action needs tighter scoping, an audit record, or human approval.

What the control plane actually does — inventory, identity, policy, and audit above the execution layer

The control plane makes those decisions for the organization above the execution layer. It records which agents and servers exist, which identities they may use, what they may do, and what happened. Permissions come from the organization’s identity provider. A policy engine then evaluates each request against user identity and group membership before execution. Authentication and authorization have separate jobs here.

That distinction makes the control plane governance infrastructure. Its inventory establishes sanctioned servers and machine identities, while structured logs, trace IDs, and metrics join activity into a unified audit trail. Versioning and kill switches allow a capability to be rolled back, an agent suspended, or a permission revoked without changing execution servers. Cost tracking and evaluation results can also inform policy decisions. Together, these records connect a tool call to the initiating human, the policy that permitted it, and the skill version that ran.

How do agents respect each user’s permissions throughout a multi-step pipeline, not just at login?

The permission model breaks when connection-level access stands in for action-level authorization. MCP connections typically inherit the authenticating user’s or service account’s permissions, giving an agent access beyond what its current task needs. A sales manager’s access is not a task specification. To keep least privilege, each downstream call needs authorization within the calling user’s scope and what the task permits, even after the initial login.

The MCP team’s Enterprise-Managed Authorization extension, or EMA, is a genuine advance at the connection layer. Stabilized in June 2026, it replaces per-server consent prompts with an enterprise identity-provider flow. Its documentation distinguishes that function from runtime authorization for individual actions. Identity controls establish who may connect, while the policy layer determines which tools the connected agent may call, with what data and for what purpose.

Conflation also breaks accountability across the chain. Each connector has its own logs and security model, so there is no shared record of the workflow. Local stdio servers make that gap especially stark because security teams lack centralized visibility, revocation, and configuration-drift detection.

How a production control plane is structured — the four components that separate governance from execution

A production architecture brings together four components, which are routing, a policy engine, observability, and a registry. The routing layer maps tool namespaces to backend MCP server URLs and checks their health. Administrators set up team profiles in place of handing out individual server addresses. Sales might receive CRM read/write and Slack tools, Engineering GitHub, Jira, and CI tools, and Finance accounting read tools.

The policy engine evaluates each request before it reaches execution. Observability records structured logs, metrics, and trace IDs so that activity remains attributable to the human and policy that authorized it. The registry supplies the approved inventory and policy references that make those decisions consistent. Each component has a distinct job to do. Routing chooses the destination, policy permits the action, observability records it, and the registry establishes which capabilities belong in the system.

The gateway pattern puts this separation into practice. Adding a server becomes a registry configuration task rather than a change coordinated across every team’s clients. Remote Streamable HTTP services provide the centralized path this architecture needs for shared enterprise resources. Local stdio processes go around that path and stay outside its governance.

The registry as the control plane’s persistent record of what agents are allowed to be

A registry is the authoritative record of sanctioned capabilities, their owners, and the versions currently in force. Without that record, governance has no persistent memory. A mature registry includes approved inventory, package and dependency scanning, identity linkage, gateway policy references, per-tenant authorization rules, data classification, and observability hooks. Unknown servers should be blocked at the network layer.

Ownership and versioning also make reuse governable over time. Another team can discover a sanctioned skill, understand who owns it, and reuse it under its own access scope. When a skill changes, its version history makes the change auditable and rollback possible. A shared drive of prompt files cannot provide that record. The registry therefore preserves both the capability and the terms under which the organization allows it to operate.

How the control/data plane split enables safe scaling across teams without duplicating effort or fragmenting permissions

Without shared governance, every adopting team must configure servers, define permissions, and establish logging for itself. That duplicates infrastructure while producing inconsistent decisions about who may access what. With a shared control plane, a new team’s access profile requires only configuration. Access is based on the identity-provider permissions already in place. The team can keep its chosen agent or chat interface because scoping does not depend on a shared user interface.

Block, formerly Square, illustrates the organizational reach of MCP through its company-wide deployment via the Goose agent, with most servers built in-house. Its layered tool pattern used less of the context-window. That result is separate from Anthropic’s code-execution benchmark. Shared configuration provides a way to govern organization-wide access without requiring every team to rebuild the connection layer.

Centralization need not mean waiting for central IT to approve every change. A well-designed registry delegates capability ownership to domain experts, while central infrastructure sets the policy framework and gateway rules. Teams own and publish skills under those rules. The shared control plane removes repeated governance work without taking domain decisions away from the people qualified to make them.

Department-level examples of where the control/data plane boundary becomes visible in practice

In RevOps and Sales, Salesforce MCP servers execute CRM reads and writes for pipeline, contact activity, and deal-health work. The control plane distinguishes read from write access by role and records each data access. CRM permissions need more than a successful login. Without task-level scoping, an agent authenticated as a sales manager can reach everything that manager can access, including sensitive compensation data and deal terms.

In Engineering, servers for GitHub or GitLab, Jira or Linear, and monitoring or cloud services support code review, CI/CD monitoring, incident remediation, and test generation. The control plane supplies human confirmation gates before high-risk mutations. A writable production pipeline raises the stakes. Without a separate kill switch, a misconfigured agent becomes a deployment risk that cannot be contained independently of the execution services.

In Support, an agent may use separate servers for ticketing, payment, and the knowledge-base. The policy engine must limit refunds to eligible cases and amounts, while the audit trail records refund actions for reconciliation. Without that boundary, the ability to invoke the payment tool substitutes for permission to issue a particular refund. These departments use different execution systems, but the same gateway, registry, policy engine, and observability layer can govern them.

How model-agnosticism at the data plane makes the control plane the durable enterprise asset

A server can serve compliant clients including Claude, ChatGPT, Cursor, GitHub Copilot, Gemini, or a custom enterprise agent without server-side code changes. The lasting investment therefore sits above the model. When a contract changes or a team chooses another interface, tool definitions, authentication, authorization, and audit infrastructure can remain in place. Business context and guardrails stay with the organization, independent of any one vendor’s tooling.

Multiple interfaces also create more places where governance must apply. Slack MCP servers can ground agents in project conversations, team knowledge, and business decisions, while Cursor for Slack lets teams delegate coding tasks inside Slack. Slack’s permissions alone do not govern everything the agent can access. The same per-action policies must apply when the workflow reaches other systems.

With the Salesforce-Claude integration, access to the service and permission to act also need to stay separate. Users need a paid Claude plan and the latest Sales Cloud Enterprise edition to get full Salesforce data access in Claude. Procurement eligibility is not runtime authorization. As interfaces multiply, the control plane provides continuity across them without making the organization’s permissions depend on any one model.

What a well-governed multi-agent architecture requires — the implementation checklist for enterprise teams

Start by registering every MCP server, assigning a named owner and data classification, and blocking unregistered servers at the network layer. Then connect authentication to the existing identity provider, using EMA where supported by both server and provider. Sessions should inherit the calling user’s scope. That scope establishes the starting boundary for subsequent action-level authorization.

Next, set up the policy engine before making mutating tools available. Writes, triggers, and refunds need per-action decisions, with explicit human approval for high-risk changes such as production deployments, financial transactions, and record deletions. Add observability from the first production request. Trace IDs and structured logs should connect calls to the human identity and policy version that authorized them. Retrofitted logging cannot supply a complete contemporaneous record of actions that were never captured.

Build versioning and ownership into the registry so sanctioned skills are discoverable and reusable across teams. For servers touching databases, internal APIs, or SaaS systems, use remote Streamable HTTP services behind the gateway, reserving stdio for local tooling limited to the developer’s own files. These choices establish a common operating boundary. Within it, domain experts should own their skills and business context, while central infrastructure owns the policy framework, registry, and gateway.