What is an AI agent control plane?

Every company is now running AI agents. Some you sanctioned; most you didn’t. A support team wired an agent into your CRM. A finance analyst gave one read access to the data warehouse. A vendor’s “AI assistant” holds a token that can send mail as your domain. None of them share a boundary, a policy, or a record.

This is the same moment the industry hit with human access a decade ago — except agents act in milliseconds, at machine scale, and can be steered by a paragraph of untrusted text. The answer then was an identity and access layer that everything routed through. The answer now is an AI agent control plane.

The one-sentence definition

An AI agent control plane is the layer that sits in the path of every action an agent takes, so you can decide what each agent is allowed to do, enforce that decision before the action runs, and prove afterward exactly what happened.

If a control hides behind that path — a linter, a prompt instruction, a code review checklist — it isn’t a control plane. The defining property is interposition: the agent cannot reach a tool, an API, or a secret without going through the plane.

Why “in the path” is the whole game

Most agent governance today is advisory. You write a system prompt that says “never delete customer records.” You add a guideline to the runbook. You hope the model complies. But a system prompt is a suggestion, and a sufficiently clever prompt injection — or just an unlucky sampling step — routes straight around it.

A control plane removes the hope. The check is not a string the model reads; it’s code that runs between the agent and the resource. When the agent calls crm_delete_record, the request hits the plane first. The plane evaluates your policy. If the answer is no, the call never reaches the CRM. The model can want to delete the record all day — there’s simply no path.

The three jobs: scope, guard, log

A control plane does three things, and they map cleanly onto questions every security team already asks.

1. Scope — what is this agent allowed to do at all?

Scope is least privilege for agents. Each agent gets a deliberate set of capabilities — mail_send, crm_read — defined once as a reusable role and applied across the fleet. Crucially, anything you don’t grant isn’t merely denied; it’s invisible. An ungranted tool never appears in the agent’s manifest, so a prompt-injected “reveal the vault key” request has no tool to call.

2. Guard — given that it’s allowed, should this action run now?

Scope answers “can this agent ever send mail?” Guard answers “can it send this mail, to this domain, at this volume?” Guards are your business rules expressed as enforcement:

• Send only to approved domains.
• Cap spend at $500/day per agent.
• Require human sign-off for any payment over $1,000.
• Block destructive actions during a change freeze.

The guard runs before the side effect. There is no “we’ll catch it in the nightly report.”

3. Log — what actually happened, and who’s accountable?

Because the plane is in the path, it can record every action — allowed and denied — as it happens, not reconstruct it later from scattered application logs. Each entry is immutable, exportable, and attributable: it traces from the agent identity back to the human who owns it. That’s what turns “the agent did something” into “Maya’s billing agent attempted a $40 refund at 14:02, allowed under the Billing role.”

A request, traced through the plane

Here’s the lifecycle of a single agent action:

agent → control plane
        ├─ authenticate agent identity
        ├─ SCOPE   is `payments_pay` in this agent's role?      ✓
        ├─ GUARD   amount ≤ daily cap? recipient approved?      ✓
        ├─ GUARD   amount ≥ approval threshold?  → human ✓
        ├─ execute call against the real payments API
        └─ LOG     write immutable record + attribution
        ↓
     result returned to agent

Every branch that says “no” stops the action and still writes a log line. A denial is as much a fact you want recorded as an approval.

What a control plane is not

• It’s not a model or a framework. It governs whatever agent you already run — LangChain, a custom loop, a vendor’s product.
• It’s not an observability tool. Dashboards tell you what happened. A control plane decides what’s allowed to happen, in the path, in real time.
• It’s not a firewall. Network rules don’t understand “refund,” “deploy to prod,” or “export PII.” A control plane operates at the level of actions, not packets.

Why this becomes non-optional

Three forces are converging. Agents are multiplying faster than anyone can track by hand. Each one is a new identity with real power and no HR file. And regulators and auditors are starting to ask the obvious question: who approved this autonomous system to move money, and where’s the record?

You can answer that question with a control plane, or you can answer it after an incident. The teams moving first are treating agents exactly like they treat employees: provisioned through SSO, governed by roles, audited centrally, and revocable in one click.

That layer — the one every agent routes through — is the control plane. It’s the difference between running agents and governing them.