TheEnterpriseAIControlPlane
As AI moves from answering questions to taking actions, the hard problem stops being model quality and becomes authority. A control plane is where authority is decided, enforced and recorded.
- IdentityWho is acting?
- OntologyWhat is being acted on?
- PolicyIs this allowed?
- ExecutionHow is it carried out?
- EvidenceWhat actually happened?
- EvaluationWas it any good?
- LifecycleWhat happens next?
Definition
An enterprise AI control plane is the layer that decides and enforces what artificial intelligence is permitted to do inside an organisation: which agents and models may access which data, perform which actions, using which tools, on which infrastructure, under whose authority, and with what evidence.
Whyagentscreateanewcontrolproblem
A chatbot creates a data problem: something was pasted into a text box. A copilot creates an accountability problem: a person shipped a draft they did not fully write. An agent creates a control problem, which is a different category. An agent plans, selects tools, calls systems and changes state — sometimes across several systems, sometimes without a person present at the moment of action.
Existing enterprise controls were designed for two kinds of actor: a human with a job title, and an application with a fixed, reviewable set of behaviours. An agent is neither. It has the breadth of access of an integration and the improvisation of a person, and it typically arrives with neither an identity of its own nor an owner who can answer for it.
That is why the useful question is not "is the model safe". It is: when this thing acted, whose authority was it acting under, what was it allowed to touch, and can you show me?
Thesevenstagesofagovernedrequest
Nothing changes state until it has passed through all of them. The order matters: policy cannot be evaluated before the request has been resolved against typed objects, and evidence cannot be assembled after the fact from logs that were never designed to carry it.
- IdentityWho is acting?
- OntologyWhat is being acted on?
- PolicyIs this allowed?
- ExecutionHow is it carried out?
- EvidenceWhat actually happened?
- EvaluationWas it any good?
- LifecycleWhat happens next?
- Identity
- Every agent, model and workflow has its own identity — not a shared service account. Non-human identities are issued, scoped, rotated and revoked like any other principal.
- Ontology
- Requests resolve against typed enterprise objects rather than free-text table names, so permissions and policies can be expressed in the organisation's own terms.
- Policy
- Data scope, tool scope, model policy, network egress, cost budget and approval requirements are evaluated before execution, not asserted in a prompt.
- Execution
- Approved work runs in an isolated runtime with short-lived credentials, brokered tool calls and a recorded plan.
- Evidence
- Inputs, retrieved context, model selection, tool invocations, approvals and outputs are captured as a reviewable trail attached to the decision.
- Evaluation
- Behaviour is scored against task-specific evaluations and regression suites, so quality is measured rather than assumed after a change.
- Lifecycle
- Promotion between environments, ownership, review dates, deprecation and shutdown are managed explicitly — including a kill switch that works.
Whatthecontrolplanegoverns
Each of these is a control surface with its own configuration, its own audit record and its own failure mode.
Non-human identity
Every agent, workflow and model integration gets its own principal with its own lifecycle. Shared service accounts are the single most common reason an organisation cannot say who did something.
Data scope
Permissions expressed against ontology objects — this asset class, these contracts, this region — rather than against table names, so scope survives schema changes and is reviewable by the business.
Tool governance
Which tools an agent may call, with which arguments, at what rate. Tool access is brokered: the agent receives a capability, not a credential.
MCP governance
Model Context Protocol servers are treated as privileged integrations. They are registered, scoped, version-pinned and monitored, because a permissive MCP server is an open path into everything behind it.
Model policy
Which models may handle which classes of data and which categories of work, including where the inference physically happens and what the provider may retain.
Execution control
Approved work runs in an isolated runtime with short-lived credentials, a recorded plan, bounded concurrency and an enforced spend ceiling.
Human approval
Actions above a risk threshold stop and assemble the case for a named approver — the proposal, the evidence, the alternatives and the consequence of doing nothing.
Evidence
Inputs, retrieved context, model selected, tools invoked, approvals given and outputs produced, captured as a reviewable record attached to the decision rather than scattered across logs.
Evaluation
Task-specific evaluation suites and regression tests, so a prompt change, a model upgrade or a policy edit produces a measured difference rather than a hopeful one.
Agent-to-agent governance
When one agent delegates to another, authority narrows rather than accumulating. Delegation is recorded, and the originating mandate bounds everything downstream.
A control plane is not a dashboard that reports what AI did. It is the path AI has to travel through in order to do anything at all.
Controlplanevsagentorchestration
Orchestration and control solve different problems and are frequently deployed together. Orchestration decides the sequence of work; a control plane decides whether the work is permitted.
| Concern | Agent orchestration | AI control plane |
|---|---|---|
| Primary question | In what order should these steps run? | Is this step allowed, and under whose authority? |
| Unit of work | Task, graph node, workflow step | Request against a typed object, by an identified principal |
| Identity model | Usually the application's credentials | A distinct principal per agent, with its own lifecycle |
| Failure it prevents | Steps running in the wrong order or not retrying | An action taken outside its mandate |
| Output | A completed workflow run | An enforced decision plus an evidence record |
| Relationship | Runs inside the control plane's boundary | Governs orchestrators as callers like any other |
ControlplanevsAIgateway
A gateway sits in front of model traffic. A control plane governs the whole action, of which the model call is one part. Most organisations that already run a gateway keep it.
| Concern | AI gateway | AI control plane |
|---|---|---|
| Scope | Model API traffic | The full request path: data, tools, actions, approvals, evidence |
| Typical controls | Routing, rate limits, key management, token accounting, PII filtering | Identity, data scope, tool scope, approvals, lifecycle, evaluation |
| Knows about your business | No — it sees prompts and tokens | Yes — it resolves requests against enterprise objects |
| Can it block an action? | It can block a model call | It can refuse an action even when the model call is harmless |
| Evidence produced | Request logs and usage metrics | A decision record linked to the affected object |
| Relationship | A useful enforcement point for model egress | Uses a gateway where present; governs more than model traffic |
ControlplanevsLLMOps
LLMOps is concerned with building and improving models and prompts. A control plane is concerned with what the resulting system is permitted to do in production.
| Concern | LLMOps | AI control plane |
|---|---|---|
| Lifecycle stage | Development, tuning, evaluation, deployment | Runtime authority and accountability |
| Owner | Data science and ML engineering | Platform, security and risk, with business owners |
| Core artefacts | Datasets, prompts, model versions, eval scores | Identities, policies, mandates, evidence records |
| Question answered | Is this model good enough to ship? | Is this action permitted right now, and can we prove what happened? |
| Overlap | Evaluation suites are shared | Consumes eval results as a lifecycle gate |
Useincriticalinfrastructure
In grid operations, water management, telecommunications and industrial process environments, the constraint is rarely appetite for automation. It is that the consequence of an unreviewed action is physical, and that the boundary between information systems and operational technology exists for good reasons.
The pattern that works is asymmetric. Observation crosses the boundary: telemetry, historian data and asset records flow out through a broker into the ontology, where agents can reason over them. Action does not cross it unattended: an agent assembles a proposal with its evidence and hands it to an operator inside the existing operational system. The platform shortens the time to a well-prepared decision without inserting itself into the process control loop.
That asymmetry is expressed as policy in the control plane rather than as a convention people are asked to remember.
Howorganisationsputoneinplace
The sequence matters more than the speed. Every step below produces something reviewable on its own.
Questions
- Is an AI control plane the same as AI governance?
- They are related but not the same. AI governance is the organisational discipline: policies, roles, risk classification and oversight. A control plane is the technical layer that enforces those decisions in the execution path. Governance without enforcement is documentation; enforcement without governance is configuration nobody owns.
- Do we need one if we only use a copilot?
- Probably not yet, and that is a reasonable position. The need appears when AI begins to take actions rather than produce drafts, when several teams start building independently, or when an auditor asks who authorised something. The useful time to design for it is before the third team ships.
- Where does it sit relative to our identity provider?
- Alongside it, not instead of it. Your identity provider remains authoritative for humans and for federation. The control plane issues and manages the non-human identities that agents and workflows act under, and resolves them against your directory for ownership and approval routing.
- Does this slow agents down?
- Policy evaluation adds latency measured in milliseconds; human approval adds as much time as the approver takes. The relevant comparison is not against an ungoverned agent but against the current process, which usually involves a person assembling context by hand before deciding anything.
- Can it govern agents we did not build on NeuroCluster?
- Yes, where they can be made to call through it. Agents that obtain credentials directly and call systems out of band cannot be governed by any control plane — which is itself a finding worth surfacing during the inventory step.
Continue
- What is an enterprise AI control plane?The long-form explainer: definitions, architecture, comparisons and FAQ.
- Enterprise ontologyWhy permissions need typed objects before they can mean anything.
- Governed agentsThe fourteen fields every agent carries before it is allowed to run.
- GovernanceRisk classification, approvals, evaluation and change control.
- SecurityZero trust for non-human identities and runtime isolation.
- SovereigntyControl across compute, models, data, identity, operations and governance.
Bring us one operational problem.
You do not need a finished brief. Bring the problem — we will work out the next step together.
Or book a call with the team