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 carries a date this year. On August 2, 2026, the EU AI Act's obligations for high-risk systems become enforceable, and Article 12 requires automatic event logging across a system's lifetime [3]. Enterprises are evaluating this layer right now, days before the deadline, and most of what is sold under the name covers a slice of the job. This article defines the layer properly, then gives you a test for anything that claims to be one.

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. The EU AI Act's high-risk obligations become enforceable on August 2, 2026, and Article 12 requires that these systems "technically allow for the automatic recording of events" over their lifetime [3]. Penalties for high-risk breaches reach 15 million euros or 3% of worldwide annual turnover. The European Commission proposed a delay in its November 2025 Digital Omnibus package; as of this writing it has not been enacted, so August 2 stands as the operative date [4].

The governance gap is now measured. Retool's May 2026 survey of 307 CTOs, CIOs, and CISOs, run with Wynter, found 93% of leaders concerned about AI-generated tools reaching production while only 4% had controls that actually reach AI-written code [1]. That is an 89-point gap between worry and enforcement, sitting in production today.

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 · Governing Agents in Production, figure 1

LOW AUTONOMYHIGH AUTONOMYBLAST RADIUSOBSERVABILITY

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 precisely the shape Article 12 asks 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 paper also opens on a number this article does not use. MIT's 2025 research put 95% of enterprise GenAI pilots in the stalled-before-production column, with governance rather than model quality as the blocker [6]. Same layer, different door. This article arrives at it from the regulator; the whitepaper arrives from the backlog of use cases nobody will sign off on.

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.

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."

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 current logging would satisfy an Article 12 evidence request filed on August 3, 2026.

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 Article 12 enforcement days away, "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.

Frequently asked questions

What is an AI control plane?

An AI control plane is the enforcement layer between an organization's AI agents and the models, tools, and data they act on. It evaluates policy inline on every request, before execution, ties each action to one unshared principal with an accountable owner, and records the prompt, identity, tool call, and result as one audit-grade record.

How is an AI control plane different from an AI gateway?

An AI gateway (or LLM gateway) governs the model call: routing, keys, rate limits, and spend across providers. It has no view of the tool call an agent makes afterward or the principal behind it. The cleaner way to see the relationship is architectural rather than competitive: in the whitepaper's reference architecture the gateway is not a rival layer but one of the execution components sitting beneath the governance layer, alongside the agent runtime, the retrieval layer, and the CI/CD pipeline, all of them clearing the same five control points on every request [5]. A control plane covers model calls, tool calls, and identity together, which is what makes end-to-end policy and single-record replay possible.

Can we assemble a control plane from tools we already own?

You can cover pieces of it. Gateways enforce at the model layer, observability platforms record outcomes, and identity providers govern login. What the assembly cannot produce is one correlated record and one consistent policy across the whole path, because each tool was architected to see a single layer. Run the Deny-Attribute-Replay test against the assembled stack and score it honestly.

Does an AI control plane satisfy EU AI Act Article 12?

It provides the mechanism Article 12 demands: automatic, lifetime event recording that a deployer can retain and produce on request. Classification of your systems, retention periods, and accountability stay with your organization; the regulation holds deployers responsible regardless of tooling. What a control plane changes is the effort: the evidence request becomes a query instead of a cross-team investigation.

What is in the whitepaper that is not in this article?

Four of the five checklist sections, the full evidence column, and the scoring rule that produces one of three verdicts on a single agent. Then the parts an article cannot carry: the component set drawn as a reference architecture, the build-versus-buy test, and a twelve-week sequence where each phase exits on evidence rather than a status update. It closes on a worked engagement, a U.S. financial services and insurance firm at roughly $800M in revenue that held 120+ approved use cases and fewer than five in production, and what twelve weeks did to that ratio [5]. Seventeen pages. Those engagement figures are anonymized and illustrative of one environment, which the paper states in the body rather than burying in a footnote.

Sources

1. Retool, "The State of AI Governance in 2026," survey of 307 CTOs, CIOs, and CISOs conducted with Wynter, May 2026: the 93% and 4% figures.

2. Gartner, press release, June 25, 2025, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027": the 40% forecast and its three named causes (gartner.com/en/newsroom).

3. Regulation (EU) 2024/1689 (the EU AI Act), Article 12 on record-keeping and the Annex III high-risk application date of August 2, 2026; penalty ceilings per the Act's enforcement provisions (artificialintelligenceact.eu).

4. Cloud Security Alliance, "EU AI Act High-Risk Deadline: Enterprise Readiness Gap," research note, March 13, 2026: status of the November 2025 Digital Omnibus delay proposal, which had not been enacted at publication.

5. Moring AI Team, enterprise whitepaper, edition 07.2026, cited across two editions that share one framework. The control plane definition, the five questions with their good and failing shapes, and the reference architecture come from the AI Control Plane edition. The thirty-six-check list and its evidence column, the scoring verdicts, the governance maturity levels, the four-approach comparison, the twelve-week plan, and the engagement figures come from the Governing Agents in Production edition. Figure 1 and the identity checklist reproduced here appear in both. Engagement figures in either edition are anonymized and illustrative of a single environment.

6. MIT, "State of AI in Business," 2025: the 95% figure for enterprise GenAI pilots that stall before reaching production, as cited in [5].

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, the Gartner forecast, and the MIT pilot-stall figure are drawn from the cited sources.