An AI control plane is the platform layer that governs every AI agent, model, MCP server, and AI-powered application in the enterprise. It discovers them, scores posture, enforces policy, inspects runtime traffic, and reports on adoption and risk – the AI-layer analog to the control planes already running for cloud, identity, and network.
- Governs agents, models, and MCP servers from one platform on one data model
- Exists because AI agents span every established security domain and fit none
- Durable controls sit at the agent layer, since the stack underneath keeps shifting
- Discovery, observation, and intervention are its three core control functions
Why is an AI control plane important?
An AI control plane matters because the security categories an enterprise already owns cannot see an agent whole. CASB governs sanctioned SaaS, DLP inspects data in motion, SIEM correlates events after they land, EDR watches endpoints, and IGA manages who may access what. An AI agent touches all five in a single session – it holds an identity, reads data, calls tools, executes actions, and reasons about what to do next.
The gap is widening. Gartner expects 40% of enterprise applications to carry task-specific AI agents by the end of 2026, up from under 5% a year earlier. IBM found that a high level of unsanctioned AI use added $670,000 to the average breach cost.
The agent layer is also where controls hold their value, because the models and protocols beneath them keep changing every few months.
What is an AI control plane?
An AI control plane is the governance and enforcement layer between an enterprise's AI systems and the business systems those systems act on. It holds the inventory of every agent, model, MCP server, and AI-powered application, scores the posture of each, enforces policy on what they may do, inspects traffic while it happens, and reports on adoption and risk.
Its control functions build on each other. Discovery establishes what exists, including the AI nobody registered. Observation captures what those systems do – prompts, responses, tool calls, and data access – as they do it. Intervention then acts on that activity before an action completes, approving, redirecting, modifying, or blocking it against policy. Each depends on the one before it, which is why they belong in one platform rather than three.
Placement is what separates a control plane from adjacent tooling. A monitoring product reports what happened. A control plane sits inline, which is what makes enforcement possible rather than advisory. It is not a model, and not a gateway alone – a gateway routes traffic, while a control plane owns the inventory, the posture, the policy, and the record.
Types of AI control planes
Control planes differ along two axes that matter more than feature lists: where they sit relative to traffic, and what they were originally built for.
Inline platforms proxy agent and MCP traffic, which is what allows an action to be modified or stopped before it executes. Out-of-band platforms observe through APIs and logs – lower friction to deploy, but limited to detection and reporting after the fact. Enforcement requirements decide which one an organization actually needs.
The second axis is origin. Some control planes were designed for the agent layer from the start, with a data model built around agent identity and multi-step reasoning. Others extend a CASB, CNAPP, or DLP product outward to cover AI. Retrofitted platforms inherit assumptions from their first category – users rather than agents, files rather than actions – and those assumptions surface as gaps once agents call tools on their own.
Coverage breadth is the third practical difference. A platform reaching SaaS, cloud, endpoint, and code sees the whole footprint.
AI control plane & Onyx
Onyx is the Secure AI Control Plane – one platform for the security teams accountable for every AI agent, model, and MCP server in the enterprise.
Steering redirects or modifies an action at action time rather than only blocking it, so a task continues within policy instead of failing at the boundary. Just-in-Time access evaluates context at the request boundary rather than at role assignment, so an agent holds what a specific action requires and carries none of it forward. Underneath both, AI-native controls were built for the agent layer from day one rather than adapted from human-user tooling, which is why policy can address a tool call and the reasoning behind it against the agent identity that made it.
Those controls run across observability, security, governance, orchestration, and ROI, covering SaaS, cloud, endpoint, and code.
