enterprise AI control planes for multi-agent workflows

An enterprise AI control plane is the infrastructure layer that decides whether a company's AI agents stay stuck in pilot mode or actually run production workflows. The average enterprise now runs 37 deployed agents, a number that climbs every quarter as teams spin up their own automations with nobody centrally reviewing them, and the gap between "we use AI" and "AI runs our workflows" comes down almost entirely to whether that layer exists. Repeated attempts to find a counterexample to this while researching the space turned up none: most companies skip the control plane, and that's the wrong call. Without one, every agent you add makes the system harder to secure and no easier to scale.

Those 37 agents are rarely a matched set. One team runs Claude for code review, another runs Cursor for development, customer support leans on ChatGPT, and a domain team somewhere has built something custom for underwriting or claims triage. Left alone, each team manages its own tool connections, its own authentication, its own access rules. The result is fragmented security boundaries, duplicated infrastructure, and zero visibility across agents. Work through the logic and the security perimeter ends up as wide as the single most permissive agent on the network, which is a bad way to find out what your actual risk surface looks like.

McKinsey's State of AI 2025 survey found a large majority of organizations use AI in at least one business function, yet only a smaller share are experimenting with agentic AI systems. That's a nearly 50-point gap, and it's worth sitting with, because the obvious explanation — that models aren't good enough yet — doesn't hold up. Models are already good enough for most of this work, so the gap sits in integration and governance. The pattern in every fragile pilot is identical: no shared layer enforcing consistent permissions, context, and auditability across agents. That shared layer is the control plane, and what follows breaks down what it's actually made of.

What an enterprise AI control plane actually is

A control plane is the governance and orchestration layer that sits above individual agents and models. It governs how the work gets done, coordinating permissions, context, and guardrails across every agent connected to it, rather than doing the work itself.

No single agent can provide these things on its own:

• A single enforcement point for permissions and access policy, applied consistently across every agent in the organization
• Orchestration logic for chaining agents together into multi-step workflows
• A complete audit record of which agent called which tool, when, and under what permissions

Here's the part most teams get wrong: they assume the control plane lives inside a model vendor's product. Sit with that assumption for a minute and it falls apart. A real control plane is model-agnostic. It governs context, permissions, and guardrails no matter which LLM sits underneath a given agent, because business rules and access policy belong to the organization, not to whichever vendor happens to be in favor this quarter.

In practice, this shows up as a gateway and registry layer that all agent-to-tool and agent-to-agent calls route through and get logged by. Think of it the way a network router enforces traffic policy without caring what device sent the packet. The control plane enforces agent policy the same way, without caring which model generated the request.

How Model Context Protocol became the wiring standard for control planes

MCP is an open-source client-server standard that solves a genuinely nasty math problem. Systems expose their capabilities through an MCP server; AI applications consume those capabilities through an MCP client.

Connect M AI applications to N business systems the old way, and you're looking at something close to M×N custom integrations, since every app needs its own bespoke connector to every system. MCP flips that to M+N: one standard interface per system, one standard protocol per client. Without MCP, integration complexity rises quadratically as agents spread across an org; with it, that complexity grows linearly instead.

The adoption curve backs this up. MCP server downloads went from roughly 100,000 at launch in November 2024 to over 8 million by April 2025, and the number of distinct servers grew from about 50 at launch to somewhere between 8,000 and 12,000 by Q2 2026. That's fast, even by AI-tooling standards.

Governance now sits with the Linux Foundation. Anthropic donated MCP to the Agentic AI Foundation in December 2025, co-founded with Block and OpenAI, which makes it a neutral, industry-governed standard rather than a single vendor's product. Gartner's 2025 Software Engineering Survey projects that by 2026, 75% of API gateway vendors and 50% of iPaaS vendors will ship MCP features. MCP is getting absorbed into the enterprise stack as core infrastructure.

None of that means MCP alone solves governance, though, and this is where a lot of teams stop reading too early. The protocol gives you the wiring. It says nothing about who's allowed to call what, whether that call gets logged, or which skills are approved for use. That's the policy layer, and somebody still has to build it on top.

Permissions inheritance as the first load-bearing component

Here's the default failure mode: every time a team introduces a new AI tool, someone redefines access rules from scratch. Multiply that across 37 agents and you get permission drift, where the AI layer ends up granting more access than the source system allows, or sometimes less, and nobody notices until something breaks or leaks.

Permissions inheritance fixes this at the root, and it's the piece that separates a real control plane from a dashboard with a nice UI. When a user connects an agent to a data source, the agent inherits exactly the access that user already has in the source system, nothing more. Done right, this makes the AI access layer a mirror of existing IAM policy rather than a second, wider, harder-to-track surface sitting next to it. It syncs automatically, too: a user who loses access to a dataset loses it through every connected agent at the same moment, not on whatever schedule someone remembers to update a spreadsheet.

This is least-privilege applied to agents, not just to people, with each agent scoped to the minimum context and tools its task actually requires. Credential lifecycle governance follows the same logic teams already apply to IAM role grants: specify the agent, the target tool, the required permissions, and the credential lifetime, every time.

Scoped MCP servers by team or function are how this gets operationalized. Each team gets a server exposing only the tools and data it's authorized to touch, and there's no separate UI to build or maintain for it; the scoping lives at the control plane level. Compare that to a single shared, unscoped MCP server where any agent can call any tool. That's easier to stand up on day one. It's nearly impossible to audit or fix once something goes sideways, and something always eventually goes sideways.

Agent chaining and how orchestration turns isolated agents into workflows

A single agent handles one bounded task well. A workflow needs several agents handing off context, results, and control, either in sequence or in parallel, and that handoff is exactly where most homegrown setups fall apart.

Agent chaining is the control plane's answer: it decomposes a complex task, routes each sub-task to the agent best suited for it, and aggregates the results, all without the calling agent needing to know anything about the internals of the agents it's calling.

MCP's November 2025 spec update made this viable at production scale, and three additions matter most. Asynchronous execution support means long-running tasks no longer block the whole orchestration layer while they finish. Modern authorization primitives let agents call downstream agents with scoped, delegated credentials instead of passing along a full-access token. Session management now supports both stateless and stateful exchanges, so context persists across a multi-step workflow instead of getting re-fetched at every hop.

The 2026 roadmap adds Agent-to-Agent coordination as a first-class MCP capability, pushing MCP from single-agent tool connections into genuine multi-agent infrastructure.

Still, none of that matters if policy enforcement stops at the individual agent, which is the mistake to watch for. The control plane has to specify which agents can call which downstream agents, and what those calls are allowed to trigger. Skip that step and a fully permissioned agent can hand off work to one that isn't, quietly breaking the least-privilege model the inheritance layer was supposed to guarantee. Canva's rollout of AI agents across 500 employees, built on an enterprise MCP orchestration layer, is an early example of governed chaining at real scale.

Auditability as the mechanism that makes governance real rather than nominal

Governance without auditability is a policy document sitting in a drive somewhere. If nobody can see which agent called which tool, using whose credentials, on what data, at what time, then none of the permissions logic described above is actually enforceable. It's aspirational, and aspirational governance fails the exact moment someone needs it most.

A production-grade audit log for multi-agent workflows needs to capture agent identity and the model behind it, the tool called along with its inputs and outputs, and the permissions context active at the exact moment of the call, not whatever the current permissions happen to be. It also needs an approval chain: who signed off on the version of the skill or workflow that just ran.

This is also how shadow MCP gets caught. Without a centralized gateway logging all MCP traffic, teams stand up unofficial servers outside the control plane constantly, usually with good intentions and zero visibility to anyone else. A working audit layer is what surfaces those before they become the incident report.

Data loss prevention belongs at the gateway level too, and it needs to run before execution, not after. Outbound tool call payloads get inspected as they go out, which is what allows a control plane to catch problems before they happen rather than after, and it's not a subtle distinction; it's the whole point.

For organizations under SOC 2, GDPR, or similar frameworks, none of this is optional. You cannot route tool calls through external infrastructure without documented evidence of what data moved where, and the audit log is that evidence.

Audits of current MCP registries surface four recurring gaps: no server-level access restrictions, so any agent can connect to any registered server; no audit trail at the registry level; no access governance across users, groups, or agents; and data egress risk when hosted registries route calls through external infrastructure. Every one of those is a governance failure hiding behind a working demo.

The governed skill registry as the mechanism for scaling without duplication

Without a shared registry, five teams end up building the same prompt, the same integration, and the same access logic for the same underlying system, five separate times. The cost isn't just wasted engineering hours. It's five slightly different versions of the same business logic, each drifting on permissions and each carrying its own audit gap.

A "skill," in this context, is a pre-orchestrated business action: logic, approvals, data handling, retries, and error recovery, all bundled into one reusable, versioned artifact with a named owner and a change history.

A registry gives you version control, so every change is tracked and rollback is possible. It gives you ownership, so each skill has a team responsible for it. It gives you access scoping, so a skill can be published org-wide or locked to one team, and it gives you discoverability, so agents and developers can find approved skills without knowing who built them or digging through Slack threads.

A federated registry model is worth adopting: central IT maintains the list of approved servers and skills for the whole organization, while each line of business also publishes its own, either just to its own team or, optionally, out to everyone else. Domain experts own the content of their skills. Central IT maintains the rails those skills run on.

MCP Server Cards, on the 2026 roadmap, push this further by enabling automatic discovery, so agents can find and connect to compatible servers in the registry without manual configuration. That turns the registry from a static list into a live, queryable catalog, applying the same efficiency MCP delivers at the protocol level, M+N instead of M×N, to the organizational level as well.

What the control plane looks like in operation across different teams

In RevOps, an agent chain might pull CRM data, analyze deal stage, and generate a forecast across three specialized sub-agents. Permissions inheritance keeps a sales rep's agent scoped to that rep's book of business, not the entire CRM, and once the forecast skill is published to the registry, Finance can reuse it without rebuilding a thing.

In engineering, a code review agent, a dependency scanner, and a deployment gate run as a chain triggered the moment a pull request opens. Each agent stays scoped to the repos and environments its team is actually authorized to touch, and the audit log records exactly which version of the review skill approved which PR, a detail that matters a lot in a regulated environment come audit season.

In support, a customer-facing agent might pull account data, escalation history, and product docs in one orchestrated call. Filtering happens at the gateway, so the agent surfaces only what the support role is authorized to see, even when the underlying systems themselves hold much broader access.

The multi-surface piece ties all of it together. The same governed skill and the same permissions logic should behave identically whether someone reaches the agent through Claude, ChatGPT, Cursor, or Slack. That consistency is the control plane's job, not any individual surface's job. Strip the control plane out of any of these examples and it reverts to the old pattern: same data, rebuilt access logic, no shared audit trail, no reusable skill, just another one-off integration waiting to drift out of sync with everything else.

How to assess whether an existing AI deployment has a real control plane or a nominal one

Most companies that think they have a control plane actually have a gateway with good intentions, and that distinction is the whole ballgame. The test isn't whether agents are connected to tools. It's whether anyone can answer, on demand, who approved a given skill, what permissions were active during a specific call made three weeks ago, and whether a permissioned agent ever handed work to one that wasn't.

Start with permissions. Pull up any connected data source and check whether access syncs automatically when a user's role changes upstream, or whether someone has to remember to update it by hand. Manual is the tell. If IT has to go update AI access separately from updating the underlying system, that's a parallel system waiting to drift, not real inheritance.

Then check chaining. If agent A can call agent B, is there a policy layer that actually defines what B is allowed to do on A's behalf, or does A's credential just pass straight through? A permission system that only exists at the single-agent level stops being a permission system the moment chaining enters the picture. Treat it as a gap with a policy document taped over it.

Auditability is the fastest gut check of all. Ask for the log of every tool call a specific agent made last week, including the permissions context active at the time of each call. Its absence, or its presence without a permissions snapshot, makes the audit trail nominal, good enough for a demo but not for an actual security review.

Last, look at duplication. Are three different teams maintaining three different versions of essentially the same integration to the same CRM or data warehouse? That's the clearest sign there's no registry, just parallel effort dressed up as independent innovation.

Platforms built specifically around this problem, Credal among them, provide permissioned MCP servers alongside a governed agent registry, so every call an agent makes is both logged and automatically scoped to whatever permissions the calling user actually has. Working through these examples, the same pattern shows up every time: a real control plane takes the shape of infrastructure that makes the policy impossible to skip, backed by mechanisms rather than good intentions. Judge any AI deployment against that bar, and the gap between an experiment and a system built to last gets easy to see fast.