What an AI Control Plane Is, and the Three-Question Test for Evaluating One

TL;DR

• An AI control plane checks whether an agent’s proposed action is allowed before it reaches a business system.
• Test it with three questions: can it deny an unauthorized action, attribute an action to the right identities and reconstruct what happened from the retained record?
• A dashboard or gateway may supply part of the answer. Your evaluation needs evidence that the controls hold across the whole action path.

What an AI Control Plane Is, and the Three-Question Test for Evaluating One

An AI control plane is the layer that checks every agent action against enterprise policy before it runs. It sits between the agent runtime and the systems that runtime touches, and on each request it resolves who is acting, whether the action is allowed right now, where its data and calls may reach, and whether the result is recorded, with the authority to stop the action before it commits. Governance stops being something each team writes into each agent and becomes a property of the platform, so no single agent can exceed the boundaries that platform sets 5.

That definition has a regulatory deadline behind it, and the deadline has moved. Under Regulation (EU) 2026/1744, the AI Act’s Chapter III obligations for stand-alone high-risk systems under Article 6(2) and Annex III apply from 2 December 2027. The corresponding obligations for high-risk AI built into products under Article 6(1) and Annex I apply from 2 August 2028. Article 12 still requires automatic event logging across a system’s lifetime.

What this article covers

• A plain definition of the AI control plane and where it sits in the enterprise stack
• The three dated forces that made the layer urgent in 2026, each with a source
• The five control points every agent action has to clear, and the three-question compression that survives a vendor meeting
• Why gateways, observability platforms, and identity providers each fail the test on their own
• One section of the thirty-six-check version, reproduced from our whitepaper, evidence column included
• The scoring rule: which two control points fail an agent outright, regardless of the rest
• An eight-item self-assessment your platform team can run this week, one covering every control point

What is an AI control plane, in plain terms?

It is the single checkpoint every AI action in your company passes through: one place that knows who is asking, checks what they are allowed to do right now, bounds where their data and calls may reach, writes down what happened, and can stop the action before it commits. The term comes from networking, where the control plane makes routing and policy decisions while the data plane moves the packets. The split carries over to AI cleanly.

In an enterprise AI stack, the control plane decides which identities can invoke which models and tools, under which conditions, at what cost, and it keeps the evidence. Execution stays in the data plane: the inference call to a model provider, the tool invocation over MCP (Model Context Protocol), the handoff between agents. Platform teams change routing, budgets, and policy at the control plane without touching agent code.

A useful mental picture: your agents are employees who never sleep and act at machine speed. The control plane is the badge reader, the approval chain, the door list that says which rooms exist at all, the security camera, and the switch that ends the shift, fused into one system that sits in the path of every action. Those five map exactly to the control points the whitepaper names, and the mapping is the point rather than a coincidence.

Key distinction: The data plane executes; the control plane decides. Any product that only watches the data plane, however beautifully, is reporting on decisions it never made.

Why did this land on every CTO’s desk in 2026?

Because three forces converged, each with a date attached. Regulation acquired a deadline, agents multiplied faster than anyone assigned ownership, and the surveys quantified the distance between concern and control.

The regulatory force is the hardest. Article 12 requires high-risk AI systems to technically allow automatic event recording across the system’s lifetime 3. Regulation (EU) 2026/1744 changed when the corresponding Chapter III obligations apply: 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and 2 August 2028 for systems classified as high-risk under Article 6(1) and Annex I 4. Penalties for breaches of the requirements and obligations listed in Article 99(4) can reach 15 million euros or 3% of worldwide annual turnover 3.

The governance gap is now measured. Retool’s June 2026 vendor-sponsored survey of 307 CTOs, CIOs, and CISOs, run with Wynter, found 93% of leaders concerned about AI-generated tools reaching production while only 8% described their internal-tool governance as strong 1. That is an 85-point gap between concern and confidence in the controls already in place.

And the cost of getting this wrong has a forecast. Gartner predicted on June 25, 2025 that over 40% of agentic AI projects will be canceled by the end of 2027, naming escalating costs, unclear business value, and inadequate risk controls as the causes 2. Two of those three causes are exactly what a control plane exists to fix.

What actually breaks when the layer is missing?

Mechanism. Approval and production are two control loops that share no state. A design review runs once and prices the risk of the agent someone inspected. The agent in production holds standing credentials, acts on its own schedule between reviews, and keeps moving. You have near-total visibility at sign-off and very little an hour later, and the interval between the two is where ungoverned agents live 5.

That interval has a shape worth seeing, because it explains why adding autonomy quietly adds risk that no dashboard reports.

Excerpt · The Enterprise AI Control Plane, figure 1

Figure 1. The exposure band. As an agent is trusted with more actions, potential impact climbs while visibility stays flat. The shaded band is ungoverned exposure. Reproduced from the whitepaper 5. Legend: The coral curve is blast radius rising with autonomy. The grey dashed line is observability, which does not follow on its own. The band between them is the interval where an agent acts and nobody can account for it.

Attribution breaks first. A production agent typically runs on a shared service account, so when one credential leaks, every database that account can read and every API it can call is exposed at once. When a single user request fans out into a dozen tool calls across five internal systems, each call inherits that same anonymous authority.

Then the audit breaks. Here is what an incident review looks like without a control plane, from experience: the model gateway logged a completion, the tool side logged an API call from an account named svc-agents-prod, and the identity provider logged nothing, because no human authenticated anywhere near the action. Three systems, three timestamp formats, zero shared correlation ID. Reconstructing one incident means grepping all three and lining the clocks up by hand, and “who did this” still ends in a guess.

Cost breaks last, and it surfaces at the worst time: invoice close. Token spend scatters across provider dashboards, application logs, and the cloud bill, so nobody can attribute it to a team or a use case until finance asks. Budgets that exist only as dashboards are observations. Enforcement happens before the spend or it does not happen.

The Deny-Attribute-Replay test: how to evaluate an AI control plane

Strip away the vendor decks and every agent action has to answer five questions before it runs. Who is acting, is this allowed right now, where can it reach, is it recorded, and can it be stopped. Moring’s whitepaper names those five control points identity, authorization, egress, audit, and containment, and holds any platform to all of them 5.

Five is the right number on paper and the wrong number in a meeting, so the version that travels is a compression down to three. Moring calls it the Deny-Attribute-Replay test: Deny carries authorization, egress, and containment; Attribute is identity; Replay is audit. Each question below comes with the shape of a good answer, the shape of a failing one, and a demo you can demand in the room. The good and failing shapes are the whitepaper’s, quoted as written 5.

1. Deny: can it stop an action before execution?

The requirement. Enforcement has to live inline on the request path, evaluated on every call, before the tool executes or the tokens stream. A layer that cannot say no is not a control plane. It is a dashboard.

The detail that separates real enforcement from decorative approval: policy has to bind to a pinned tool definition. A tool your team approved on Monday can change its own definition by Wednesday, and if the plane only checked at connection time, that approval now covers behavior nobody reviewed.

Where it reaches counts as much as whether it runs. This question carries egress, which is the control point most evaluations skip: the destinations an agent may call, the tools it may load, and the data allowed to leave with them. A credentialed process with open network reach passes every authorization check you wrote and still walks regulated data out of the building.

Why inline is not a stylistic preference. Evaluate policy inline and a violation is a synchronous denial measured in milliseconds. Evaluate it out of band and the floor on detection becomes your sampling interval, measured in minutes or hours. The action has committed either way; only one of the two stops it 5.

Good: a policy decision point consulted on each call, declared destinations with scoped tools, and a kill switch with budgets and sign-off on high-risk calls. Fails: permissions hard-coded once and re-checked never, open network reach from a credentialed process, and finding the limit during the incident 5.

The demo to demand. Ask the vendor to change a tool definition mid-session, then show you the block and the rule that fired.

2. Attribute: who is actually acting?

The requirement. Every agent holds a workload identity of its own, distinct from the person who deployed it, issued by the same provider that serves your people, scoped, short-lived, and shared with nothing else. That principal has to survive the whole action rather than the first hop of it, propagating across every tool call and model hop, so that the first and last entries in a trace name the same actor.

The tempting shortcut is to run agents as the human who triggered them. It demos well and it corrupts the record: the agent then holds that person’s authority between requests, and the log says a person acted when no person did. What attribution needs is a chain rather than a borrowed name. The agent’s own principal, the owner accountable for it in your access reviews, and the human who started the run where one did. Shared service accounts break that chain at the first link, which is why a one-to-one map of agent to principal sits on the checklist further down this page. Deprovisioning has to propagate as well: when an identity dies in Okta or Entra, the agent access tied to it dies in the same minute.

Good: a workload identity unique to the agent. Fails: a shared service account no audit can tell apart 5.

The demo to demand. Pick one tool call in the log and ask the vendor to walk the chain out loud: which principal, which owner, which human started the run. If the answer is a key name or a team, you have traffic attribution and an accountability gap.

3. Replay: can one query reconstruct an incident?

The requirement. The prompt, the principal, the tool call, and the result have to land in one correlated, tamper-evident record your team can query and export, and denials have to be recorded as completely as successes. This is an implementation approach to supporting Article 12’s requirement for automatic recording, across the lifetime of the system, retrievable when a regulator or an auditor asks 3.

Good: an attributable record per action. Fails: a log line with no subject and no chain 5.

The demo to demand. Name yesterday’s date and ask for a full reconstruction of one session in a single query, live. Count how many browser tabs the sales engineer opens. Every extra tab is a seam an incident will eventually fall through.

Where the tools you already own stop short

Every category in the current stack passes one of the three questions and fails the other two, which is why assembling a control plane from existing tools produces governance with seams in it. The table below is the short version, scored on three questions. The whitepaper runs the same exercise across five control points instead of three, against a different cut of the market.

None of this is a criticism of those tools. Each was built to own one layer and owns it well. The gap is the path between the layers, and no single-layer product closes that path by shipping a feature. Widen the test past three questions and the picture gets worse before it gets better.

What those five look like at full length

Everything above is the version that fits in a meeting. The whitepaper does not compress: the same five control points open out into thirty-six checks, and every check carries a named piece of evidence someone has to produce 5. That ratio, three questions against thirty-six answers, is the honest distance between understanding this layer and being able to prove you run one.

It also explains why the compression costs something. Deny carrying authorization, egress, and containment at once is fine for a first pass and useless for a decision, because a platform can hold a policy decision point and an egress allowlist while having no way at all to stop an action already in flight. The checklist keeps the three apart so that gap has somewhere to show up.

The column that makes a checklist hard to fake

Beside each of the thirty-six checks sits an artifact someone has to produce on demand, in production, today. Not a slide. Not a config in staging. The paper’s instruction on this runs to one sentence, and it is the sentence that turns a checklist into an audit: a ticked box with nothing behind it is an opinion 5.

Here is one of the five sections in full, lifted from section 03. It is the identity section, which is what Attribute looks like when you stop compressing it.

Excerpt · The Enterprise AI Control Plane, section 03, the agent production checklist

01 · Identity. Who is acting?

Seven checks of thirty-six. The other four sections cover authorization, egress, audit, and containment, and the scoring rule below is what makes the arithmetic uneven.

Two of the five decide whether the agent ships at all

Scoring is the point where a checklist stops behaving like a feature matrix. The gaps are not weighted equally. Any unticked item under identity or containment fails the agent outright, whatever the other three sections score, because those two govern whether an incident is recoverable at all: without identity you cannot attribute the action, so you cannot scope the damage or prove what was untouched, and without containment you cannot end it. The other three sections only change how often you need either one.

Identity is the section printed above. Containment is the one you have not read, and it is also the column that comes up empty for all three conventional approaches the paper scores: guardrails written per app, single-cloud native AI security, and observability tooling. Every one of them fails it. The specific evidence the paper asks for is a dated dry-run record of stopping one agent without stopping the platform, which is a different artifact from a documented procedure, and the difference tends to surface at the worst possible moment.

A way to name where you actually are

A score on its own tells a steering committee very little. The paper maps it onto four levels instead, which helps when the honest answer to “are we governed” is “partly, and only in two teams.”

Excerpt · The Enterprise AI Control Plane, figure 2, governance maturity

Level 0 · Post-hoc. Logs reviewed after the fact. Detection runs in hours.

Level 1 · In-code. Guardrails written per app. No shared state across teams.

Level 2 · Per-team. Policy per squad. Drifts as teams and tools multiply.

Level 3 · Inline enforcement. One decision point every request passes. Shared infrastructure.

Moring’s reading is that most enterprises sit at Level 0 or 1 for agents today 5. Level 3 is the control plane this article describes.

One line governs the whole framework, and it is worth carrying out of here even if you never open the paper: inline, or it does not count. Any of the five answered after the action instead of before it gives you a report where you needed a control.

What an AI control plane does not solve

It does not make your agents good. Output quality, hallucination, and task success are evaluation problems, and a perfectly governed agent can still produce a wrong answer with full audit coverage. Budget for evals separately.

It cannot repair over-permissioned backends. If the database API behind a tool grants admin scope to everyone, a control plane in front of it narrows the blast radius without fixing the underlying grant. The plane enforces authority; someone still has to design that authority well.

It stays out of how AI-written code reaches production. That is a delivery-lifecycle problem with its own stages, owners, and evidence trail, covered separately under AI-DLC.

And it costs you something: a dependency in the hot path. Milliseconds of latency on every call, plus a fail-open-or-fail-closed decision your team has to own before the first outage, because whichever you pick will be tested. Weigh that honestly. The teams that regret this layer are the ones who pretended it was free.

An eight-item first pass to run this week

These eight are the thirty-six compressed down to what one platform lead can answer in an afternoon, spread so that every control point gets tested at least once. Score a point per honest yes, and only where you could put the evidence on a screen today. Anything below seven is the gap this article describes, and the distance between your score and seven is your evaluation shortlist.

1. You can name, today, every MCP server and tool an agent in your company can reach.

2. Every agent runs under its own scoped, short-lived workload identity, issued by the same provider that serves your people, with no shared service account anywhere in the path, and deprovisioning that identity ends its agent access within minutes.

3. Policy is evaluated before each tool call executes, against a pinned tool definition.

4. Data is classified and checked against its destination before it leaves, and your model providers are treated as an egress destination like any other.

5. One query reconstructs a full incident (prompt, principal, tool call, result) without opening a second system.

6. You can stop one agent without stopping the platform, and someone has rehearsed doing it on a date you can name.

7. Budgets and loop caps are enforced per agent before spend occurs, and finance can attribute AI cost by use case.

8. Your logging can produce the Article 12 record for the relevant high-risk system class by its applicable Chapter III date.

Key takeaway

The question to carry into any vendor conversation is short: can this system deny an action before it executes, attribute it to one unshared principal, and replay it from one record? Ask it of every gateway, platform, and homegrown stack that claims to govern AI. Most will pass one of the three.

The control plane is the layer that passes all of them, and with the Article 12 logging requirement unchanged, “we log most of it” has stopped being an answer. Moring builds its AI Control Plane, the AICP, at exactly this checkpoint: the point where an agent’s intent meets the authority it was actually granted.

If your score comes back at five or six, the shortest useful next step is not a vendor call. Take the identity section printed above, run it against your highest-volume agent, and see how many of the seven have an artifact behind them. Whatever you cannot produce is where your next quarter starts.

The whitepaper

The Enterprise AI Control Plane · Moring whitepaper, published 11 September 2026, 21 pages.

The paper explains the control-plane decisions between an AI pilot and production: who can act, which tools can be used, what must be reviewed, and how every decision is traced. It covers identity, policy, approvals, observability, cost control, and a practical path from one workflow to enterprise scale 5.

Worth having open before your next vendor call, or before you score your own highest-volume agent. Request the whitepaper.

Sources and further reading

1. Retool, “The State of AI Governance in 2026”, published 17 June 2026: vendor-sponsored survey of 307 CTOs, CIOs, and CISOs conducted with Wynter; cited for the 93% concern and 8% strong-governance figures.

2. Gartner, “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027”, published 25 June 2025: cited for the forecast and its three named causes. Automated access to the publisher may be restricted.

3. Regulation (EU) 2024/1689 (the EU AI Act), Article 12 on record-keeping and Article 99 on penalties.

4. Regulation (EU) 2026/1744, which amended Article 113 of the AI Act: cited for the 2 December 2027 and 2 August 2028 application dates for the relevant Chapter III obligations.

5. Moring, “The Enterprise AI Control Plane”, published 11 September 2026, 21 pages: cited for the control-plane framework, reference architecture, production checklist, evidence requirements, and maturity model reproduced in this article.

Editorial note: the Deny-Attribute-Replay compression, the checkpoint framing, and the eight-item self-assessment are this article’s own, built on the definition, the five control points, the thirty-six checks, and the maturity levels quoted from 5, all of which are Moring’s interpretation rather than an industry standard. Regulatory dates, survey figures, and the Gartner forecast are drawn from the cited sources.

Frequently asked questions