What is an AI control plane?

Where the term comes from

In networking and cloud infrastructure, the data plane is where traffic actually flows and the control plane is where routing decisions, policy, and configuration live, kept deliberately separate so a policy change doesn't require touching every packet path. Applying that split to AI agents gives the same benefit: the agent's reasoning and tool calls are the data plane, and the rules about who the agent answers to, what it may read, and what it may change live in a separate control plane that does not depend on the agent's own good behavior to hold.

What belongs inside an AI control plane

A control plane worth the name typically holds five things: an identity and role model distinct from any single agent instance; a permission set mapped to what each role and each agent can actually do, usually resolved down to an API scope; separation-of-duties rules enforced by the system, not just described in a policy document; an action boundary with policy checks, idempotency, verification, and rollback for anything that changes state; and an evidence or audit ledger of what happened, ideally tamper-evident and exportable.

What does not belong in the control plane is the agent's own model weights, prompts, or internal reasoning trace. Those are governed by the control plane; they are not part of it. A system that only has a prompt library and a chat log, with no independent record of who approved what, does not have a control plane, whatever the marketing calls it.

How the field is naming this

ServiceNow's Autonomous Workforce introduces what it calls an AI Control Tower governing its role-scoped AIOps and SRE specialist agents, with the stated properties of full audit trails, role-scoped permissions, and enterprise context. That is the same instinct under a different name, and it is a useful sign that the industry is converging on the idea that agents need a governance layer distinct from their reasoning, even where the specific implementation isn't published in detail.

A common mistake worth naming

The most common gap is treating role-based access control alone as a control plane. RBAC says who can do a thing; a control plane also has to say who must never be able to do two things together, which is what separation-of-duties enforcement adds and what the next answer page covers directly. A role table with no enforcement that a proposer can't approve their own work is a permissions list, not a control plane.

The control plane in HELM by LockedIn Labs concretely holds seven interactive roles resolving to twenty-four permissions, four fixed separation-of-duties rules, and an API-scope mapping for each role, visible in the Access workspace, with autonomy and agent-governance records in the control plane. A guest can preview roles without receiving their authority.

A worked example of the control plane doing its job

Consider an illustrative policy design with two proposals: closing a stale ticket and rolling back a recent deploy. An organization might permit the ticket closure within a narrow, preapproved action boundary while requiring independent human approval for the rollback. The approval check would reject the proposing identity; separate permission and policy checks would control execution, idempotency and the resulting receipt. These examples describe a policy design, not enabled customer actions in the hosted reference application, where customer production writes remain disabled.

In that design, the policy check sits outside the agent’s reasoning. A registered action boundary must enforce the chosen approval, execution and evidence requirements even if the agent proposes something inappropriate. A demonstration should show those checks refusing a disallowed action, rather than asking a reader to infer enforcement from a description of intended behavior. Inspect the proposing principal, the independent approver, the attempted operation and its recorded result together; a role label alone cannot establish that these checks ran.

That last point is worth restating because it is easy to miss in a demo. A vendor can show an agent behaving correctly a hundred times in a row and still not have shown you a control plane, if nothing in the system would have stopped the agent on the hundred-and-first attempt. The question worth asking is not whether the agent behaved well in the demo, but what specifically would have stopped it if it hadn't.