An agent control plane stands between your AI agent and the systems it can change. Every action goes through it. It checks the action against rules the agent cannot rewrite. Then it lets the action through, holds it for a person, or refuses it. It writes down which of the three happened.
In one sentence: the part of the stack that decides what the agent may do, kept apart from the part that does it.
Where it comes from
The term is borrowed. Network engineers split a router into a control plane, which decides where packets go, and a data plane, which moves them. Kubernetes uses the same split. A cluster "consists of a control plane and one or more worker nodes"1. The control plane components "manage the overall state of the cluster"1. The nodes run the work.
Security architects have their own version. In NIST's zero trust model, access "is granted through a policy decision point (PDP) and corresponding policy enforcement point (PEP)"2. Authentication and authorization "are discrete functions performed before a session to an enterprise resource is established"2. Nothing gets in because of where it sits. It gets in because a policy said yes, this time.
Agents bring the two ideas together. A model that wants to post a payment is a workload asking for a session with your ledger. Something has to be the decision point. It cannot be the model.
What it actually is
Take one action. Your AP agent wants to schedule a payment of 2,400.00 to a supplier. The control plane asks three questions, in order.
Is this action allowed at all? Your rules list what this agent may do. Scheduling a payment is on the list. Changing supplier bank details is not. That request would stop here, whoever asked. OWASP calls the failure this prevents excessive agency. Its root causes are "excessive functionality; excessive permissions; excessive autonomy"3. The first question handles the first two.
Is it allowed with these facts? Say your rules let payments under 250.00 to known suppliers go without review. This one is 2,400.00. The bank details on the invoice were first seen today. The control plane reads the facts of this run, not the average run.
Does a person look first? Given those facts, the rule says hold. The control plane packs the evidence and sends it to one named approver. It waits. Your approver declines, because the supplier has not confirmed the change. The payment never posts. The record shows the rule that fired, who decided, and when.
The thresholds are illustrative. Yours come from your delegation of authority. The shape stays the same: allowed, allowed now, person first.
Two more jobs happen out of the agent's sight. The control plane caps what the agent can spend or commit per run, day or month. And it writes a record the agent cannot edit. "What did it do in March?" gets one answer.
Why a prompt is not a control plane
Most agent products put the rules in the system prompt. "Never change bank details. Always ask before paying more than 10,000." It feels like control. It is a request to a component that reads untrusted text for a living.
Meta's security team is blunt about it. Prompt injection is "a fundamental, unsolved weakness in all LLMs"4. Meta names three properties: the agent processes untrustworthy inputs, can reach sensitive systems, and can change state. If it needs all three in one session, it "should not be permitted to operate autonomously and at a minimum requires supervision"4.
An invoice is an untrustworthy input. If only the model's good behaviour stands between the invoice and the payment, an invoice that says "ignore the limit" is a live attack.
A control plane is a different component. It does not read the invoice. It reads the proposed action and the rules a person signed. It does not negotiate.
What it is good at, and what it is not
Good at. Stopping the action you already know is dangerous. The payment over the limit. The bank change. The write to a closed period. Sending a hold to one named person, not a shared inbox. Producing a record an outsider can check. Letting you swap the model underneath without rewriting the rules.
Not good at. Judging quality. It can see the agent wants to close a claim. It cannot tell whether the claim should close. That is what the hold and your approver are for. It also cannot fix a bad rule. Allow "any payment under 10,000", and it will allow 400 payments of 9,999. Then it will correctly report that it did.
Not the same as three things people confuse it with. An observability tool records what happened, after it happened. A guardrail filters model text and usually knows nothing about your delegation of authority. An approval step in a workflow tool controls that one workflow, not every path to the system. The test: can your agent reach the system of record without passing through it? If yes, it is not a control plane.
What to check
- /01
Is it in the path? Draw the line from the agent to your ERP. If any route skips the component, it is advisory.
- /02
Where do the rules live, and who can change them? Rules the agent can edit are not rules.
- /03
Show me a refusal. Vendors demo the happy path. Watch it stop something. Read the record of the refusal.
- /04
Who receives a hold? A person by name, with named cover? Or a channel?
- /05
Can I take the record with me? In what format? How would an outsider prove nobody changed it?
- /06
What happens when it is down? Does your agent fail open or fail closed?
The EU AI Act wants people overseeing a high-risk system to be able "to decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output"5. They must be able "to intervene in the operation of the high-risk AI system or interrupt the system through a 'stop' button or a similar procedure"5. A control plane is where those buttons live. Without one, your stop button is a phone call to an engineer.
Where it is going
Two directions at once. Platform vendors are adding a control plane tab to products built for orchestration. That usually means a policy page the product enforces on itself. Meanwhile, independent control planes are appearing that sit across several agent platforms with one set of rules.
Our view: the second wins for any company running more than one agent. Identity moved out of individual apps for the same reason. The rules belong to your business, not to whichever tool runs the loop this year.
Gatehouse fit
Gatehouse is Surehand's control plane. Your rules are one signed, versioned document. The policy engine checks each action against it before the action runs. Held cases go to one named approver. Overriding a block takes two names. Every run ends as a record chained by SHA-256, exportable in open formats. The mechanism is on the Gatehouse page. The run it walks through is simulated and shows no customer data.
At a glance
| Category | Controls |
|---|---|
| Also called | Agent governance layer, policy enforcement layer, runtime enforcement |
| Borrowed from | Control plane and data plane (networking, Kubernetes). PDP and PEP (NIST SP 800-207) |
| Key standards or docs | NIST SP 800-207. OWASP LLM06:2025. AI Act Art. 14 |
| Typical owner | Risk or internal audit sets the rules. IT runs the component. The process owner approves holds |
| The one test | Can the agent reach the system of record without passing through it? |
Sources
- [1]Kubernetes Components, kubernetes.iokubernetes.io In text
- [2]NIST SP 800-207, Zero Trust Architecture, August 2020nvlpubs.nist.gov In text
- [3]LLM06:2025 Excessive Agency, OWASP Top 10 for LLM Applicationsgenai.owasp.org In text
- [4]Agents Rule of Two: A Practical Approach to AI Agent Security, Meta, 31 October 2025ai.meta.com In text
- [5]Regulation (EU) 2024/1689 (AI Act), Article 14: Human oversightartificialintelligenceact.eu In text
Read next
The stack for governed agents: six layers between a model and your ledger
A map of what sits between a language model and the system it changes: model, orchestration, tools, control, record, and the system of record itself.
What is an agent permission manifest?
A permission manifest is the signed list of what an AI agent may touch, spend and decide alone. Anything not on the list is refused. What one contains, and why a prompt is not one.
What is an agent approval policy?
An approval policy decides which agent actions go ahead, which wait for a person, and which never happen. Most teams have a paragraph. You need a table.
