WhatIsanEnterpriseAIControlPlane?

The term borrows from networking and cloud infrastructure, where a control plane is the part of a system that makes decisions about how traffic is handled, as distinct from the data plane that carries it. The analogy holds: an AI control plane makes decisions about what intelligence is allowed to do, while the models, agents and runtimes do the work.

It exists because of a specific change in how enterprises use AI. When AI answers questions, the risk is disclosure. When AI takes actions, the risk is unauthorised action — and almost nothing in a conventional enterprise stack is designed to reason about an actor that decides at runtime what to do next.

A control plane is not a dashboard reporting what AI did. It is the path AI has to travel through in order to do anything at all.

Enterprise AI has moved through three distinguishable phases in a short time. In the first, employees used chatbots. The governance problem was data leaving the organisation in a text box, and the response was mostly policy and network controls. In the second, copilots appeared inside tools and drafted work that a human then shipped. The governance problem became accountability and quality: a person was still in the loop, so the existing accountability structures mostly held.

The third phase is different in kind. An agent plans, selects tools, calls systems and changes state. It may operate across several systems in a single task, and it may act at a moment when no person is watching. The relevant question stops being whether the output is good and becomes whether the action was authorised.

Existing enterprise controls recognise two kinds of actor. A human has an identity, a role, a manager and a review cycle; decades of access management, segregation of duties and audit practice assume this. An application has a fixed set of behaviours, reviewed once and changed through a release process; change management assumes this. An agent is neither. It has the breadth of access of an integration and the improvisation of a person, and it typically arrives with no identity of its own and no owner.

This is the control problem. It is not primarily a model-safety problem, and it is not solved by better prompts. It is an authority problem, and authority problems are solved by putting a decision point in the path.

The first instinct is usually to write the rules into the system prompt. This fails for a structural reason rather than a quality reason: the model is the component under attack. An agent reading a ticket, a document or a web page is consuming untrusted content, and that content can contain instructions. Prompt injection is not an exotic scenario; it is the expected condition of operating on real enterprise material. A rule enforced by the component that reads the untrusted input is not a control.

The second instinct is to restrict what the agent can reach by giving it a narrow credential. This is genuinely better, and it is where most organisations should start. It runs out for two reasons. Credentials are scoped to whatever the target system's role model happens to support, which is rarely the granularity the business cares about; and a credential held by an agent for its lifetime accumulates reach that nobody re-examines.

The third instinct is to log everything and review it later. Logging is necessary but it answers the wrong question. Logs tell you what happened; they rarely tell you what was authorised, and reconstructing intent from application logs after an incident is exactly the exercise nobody wants to be doing under time pressure.

A control plane addresses all three by moving the decision outside the model, expressing it against business-meaningful objects rather than system credentials, and producing the record as a by-product of the decision rather than as an afterthought.

Everything else depends on this. If an agent acts under a shared service account, attribution is destroyed before an investigation begins, and no permission you write can be specific to that agent.

So each agent, workflow and model integration is issued its own principal — a non-human identity — with its own lifecycle. It has an owner, meaning a named person who answers for its behaviour. It has an expiry, because a permission granted indefinitely is a permission nobody will revisit. And it federates to the organisation's existing identity provider for ownership resolution and approval routing, rather than establishing a parallel directory.

Non-human identity is the least glamorous part of a control plane and reliably the highest-value first step. Organisations that do nothing else but replace shared credentials with per-agent principals and named owners have already made the rest of the programme possible.

Permissions need something to be about. If the only vocabulary available is table names, API endpoints and file paths, then policy is written in the language of systems rather than the language of the business — which means the business cannot review it and it breaks whenever a schema changes.

An enterprise ontology supplies typed objects: this asset class, these contracts, this region, these work orders, with named relationships between them. A request resolves against those objects before policy is evaluated. That is what allows a permission to say something a business owner can verify, such as "may read condition data for assets in this region but not customer records", and to keep meaning that after a database migration.

It also makes actions declarable. Rather than an agent improvising whatever tool call seems appropriate, the ontology declares which operations exist, what their preconditions are, and who owns them. A plan composed of declared actions is a plan that can be checked before it runs.

Policy is where the control plane earns its name. Evaluation happens before execution and covers more than data access: which object types and instances are in scope, which tools may be called with which arguments, which models may handle this class of data, whether network egress is permitted and to where, what the spend ceiling is, and whether this action requires human approval.

Two design properties matter. The first is default deny: an agent has what it was granted, not what its credentials happen to reach. The second is that policy is a versioned artefact with an author and a review history, not a configuration screen that drifts. When an evidence record says a decision was made under policy version 14, that version can be produced.

Because policy is evaluated outside the model, no amount of persuasive text changes it. An injected instruction that convinces an agent to attempt something outside its mandate produces a denied attempt — and a security signal.

Tools are how an agent affects the world, so tool access is where a governance model is tested. The pattern that holds up is brokering: the agent holds no credential. It requests a declared operation, the control plane authorises it against the mandate, and a broker performs the call using its own tightly-scoped identity. The credential never enters a context window, and the invocation is recorded against the decision that prompted it.

The Model Context Protocol has made tool integration dramatically easier, which also makes it the fastest route to accidentally granting an agent broad reach. An MCP server should be treated as a privileged integration rather than a convenience: registered with an owner and a purpose, version-pinned so that a server update cannot silently expand the tool surface, scoped per agent rather than allowlisted globally, constrained on arguments, and restricted on egress. A server that can call arbitrary URLs is an exfiltration path regardless of what it was built for.

Which model handles a request is usually treated as an architectural choice made once. In a governed system it is a policy decision made per request, because the constraints differ by class of work: some data must not leave a jurisdiction, some tasks require a model whose behaviour has been evaluated against a regression suite, and some providers' retention terms are unacceptable for regulated material.

Lifting the routing decision out of application code has a second benefit that matters more over time. When workloads declare what they need — capability, sensitivity class, latency tolerance, jurisdiction — rather than naming a vendor, replacing a model becomes a configuration change. Given how quickly model capability moves, that is a resilience property as much as a commercial one.

A control plane's security model starts from the assumption that prompt injection succeeds. Input filtering and injection detection are worth having as defence in depth, but they are not the control, because a control that fails when an attacker is clever is not a control.

The control is architectural: the model's output is a request rather than an instruction, and authority is enforced by a component that never reads the untrusted content. Around that sit the ordinary zero-trust mechanisms applied to a new kind of principal — short-lived credentials issued per run, ephemeral sandboxes with no persistent filesystem, default-deny egress, tenant isolation, and provenance for images, models and dependencies.

One operational point is worth making because it is easy to miss. A well-governed agent estate produces a steady stream of denied attempts, and reviewing them is one of the highest-yield security activities available. Denials show precisely where mandates and reality disagree.

Most approval queues fail the same way: they ask a person to authorise something they cannot assess, so approval becomes a formality and the control becomes theatre. The design goal is a decision, which means the approver needs the case rather than the request.

In practice that means an approval arrives with the proposal, the evidence behind it, the objects affected, the alternatives considered and — critically — the consequence of doing nothing, so declining is an informed choice rather than the safe default. It should be routed to whoever owns the affected object, resolved from the directory rather than a static list. It should expire or escalate rather than sitting indefinitely. And the approver's reasoning should be recorded, because that reasoning is often the most valuable part of the evidence.

Evidence is the record of what actually happened, captured as a decision artefact rather than reconstructed from logs. A useful evidence record contains the inputs, the retrieved context, the model selected and why, the tools invoked and their results, the approvals given with their reasoning, the outputs produced, and the versions of the policy and semantic model that were in force. That last item is what keeps an old decision interpretable after the rules have changed.

Evaluation is how quality becomes measurable. Task-specific evaluation suites and regression tests run when anything changes — a prompt, a policy, a model version, an ontology mapping — so that a change produces a measured difference rather than a hoped-for one. The most common reason a production AI system starts behaving differently is that something changed and nothing measured it.

Lifecycle covers the unglamorous rest: promotion between environments as a gate rather than a deploy, ownership that is kept current, scheduled review with a defined consequence for reviews that do not happen, deprecation, and a kill switch that has actually been tested — including revoking credentials already issued to in-flight runs.

Multi-agent systems introduce a failure mode worth naming: authority that accumulates through delegation. If agent A can call agent B, and B holds permissions A does not, then A has effectively acquired B's access — the confused deputy problem, in a new setting.

The rule that prevents it is that authority narrows on delegation. A sub-agent can never hold more than the mandate that invoked it, the delegation chain is recorded as part of the evidence, and chain depth is bounded. This is straightforward to state and easy to get wrong, because the convenient implementation is for each agent to hold its own credentials and for calls between them to look like ordinary service calls.

In grid operations, water management, telecommunications and industrial process environments, the constraint is rarely appetite for automation. It is that an unreviewed action has physical consequences, and that the boundary between information systems and operational technology exists for safety and security reasons that predate anyone's AI strategy.

The pattern that works in these environments is deliberately asymmetric. Observation crosses the boundary: telemetry, historian data and asset records flow outward through a one-directional, rate-limited broker into the semantic model, where agents can reason over them. Unattended action does not cross it. An agent assembles a proposal with its supporting evidence and hands it to a qualified operator inside the operational system that is already approved for the purpose.

The value is not autonomy. It is the collapse in time between an event and a well-prepared decision — which in these environments is usually spent assembling context from four systems rather than exercising judgement. Expressing the asymmetry as enforced policy, rather than as a convention people are asked to remember, is precisely what a control plane is for.

Starting with a platform decision rather than an inventory. Organisations that buy before they know how many agents they already have usually discover that the interesting governance problem was in the estate they did not know about.

Modelling the whole enterprise before shipping anything. Semantic modelling detached from a workload produces an ontology nobody uses and a programme that loses its sponsor.

Treating approval volume as a success metric. A queue that grows is a queue that will be rubber-stamped. The metric worth watching is whether approvers change outcomes.

Governing only what was built in-house. The agents that matter are frequently the ones a business unit assembled quickly, and a control plane that only governs the sanctioned path leaves the actual risk untouched.