An AI control plane is the layer where an organization decides and enforces what its AI applications, agents and tools may do: who they are, what they may reach, under which policy, and what was decided. It sits apart from the traffic itself, the model calls and tool calls, so the same rules apply across many models, agents and integrations instead of being rebuilt inside each one.
What a control plane holds
- Inventory and identity: which AI systems, agents and MCP servers exist, who owns them, the credentials each one uses and, in an AIBOM, what each AI system is built from.
- Policy: which actions are allowed, denied or held for a person's approval, and how much may be spent.
- Enforcement points: gateways or SDK hooks in the request path that apply the policy to live calls.
- Evidence: a record of the decisions, kept so that someone else can check it later.
How it differs from the data plane and an API gateway
The term comes from networking, where the data plane moves packets and the control plane decides where they go. For AI, the data plane is the prompts, tool calls and responses; the control plane is the inventory, policy and record that govern them. An API gateway is one enforcement point in the data plane: it can apply a rule to a request, but it does not own the inventory, the lifecycle of the policy or the evidence. The longer comparison is in AI control plane vs API gateway, and the MCP gateway entry covers the enforcement point for tool calls.
Where to go next
Architecture, components and how teams adopt one are covered in the AI control plane guide. Praesidia keeps an inventory of AI systems and the agents and MCP servers they use, and decides on the calls it governs. Praesidia records the decisions it makes in an append-only, hash-chained audit trail, signed under the default configuration; an operator can turn signing off. New policies start in observe mode, which records the decision and lets the call through, until a policy is set to enforce. How the pieces fit together is on the platform overview, and the program a control plane serves is described under AI agent governance.
Common questions
Is "AI control plane" a product category or an architecture?
Both. It names the governing layer in an architecture, and vendors also use it for products that provide that layer. When you evaluate one, ask which of the four parts it covers and where its enforcement points sit.
Do I need a control plane if I use one model provider?
Possibly not for model calls alone, which the provider's own console can govern. The need appears when agents call tools, other agents and internal systems, because no single provider sees those paths.