Home  /  Blog  /  What a Governed Control Plane Actually Looks Like
AI Governance & Evidence

What a Governed Control Plane Actually Looks Like

An AI control plane is the layer that decides what your AI systems may do, routes their requests, and records what happened — distinct from the data plane that runs the work. Most teams have one by accident. A governed control plane is deliberate: it adds three properties an accidental one lacks — machine-readable capability declaration, regulatory classification, and verifiable evidence. Here is what each of those means, and why the difference is the gap between asserting your AI is safe and proving it.

CORNERSTONETarget: ai control planePublished 2026-06-15

What is an AI control plane?

The term is borrowed from networking and Kubernetes, where the control plane decides and configures while the data plane moves the packets. In an AI system the split is the same. The data plane is the part that does the work: the model running inference, the agent calling a tool, the function returning a result. The control plane is the part that decides — what gets routed to which model, which tools an agent may call, what policy applies, and what gets written down afterward.

If you run any non-trivial AI system, you already have a control plane. The question is whether you designed it or inherited it. An MCP server that exposes tools, a router that picks models, a gateway that holds API keys — that is a control plane. It is usually an ungoverned one: it controls execution but cannot answer three questions a regulator, an auditor, or your own CISO will eventually ask.

What makes a control plane “governed” versus ungoverned?

An ungoverned control plane can route and execute. A governed one can also answer:

  1. What is this system allowed to do? — declared in a form a machine can read, not buried in a Confluence page.
  2. Under which rules does each capability fall? — every capability tagged to the regulatory regime it touches.
  3. Can you prove what it actually did? — every consequential action recorded as something you can verify, not a log you are asked to trust.

Those three properties — capability declaration, regulatory classification, verifiable evidence — are the whole difference. None of them changes what the system does. All of them change what you can say about it with a straight face.

What is capability declaration?

Capability declaration is a machine-readable manifest of what each agent, tool, and model in your system can do: its inputs, its outputs, the permissions it holds, the data it touches. Structured and queryable — not prose.

The reason prose policy fails is mechanical. A policy document is written once and drifts immediately, because the system keeps changing and the document does not. A declared manifest lives next to the capability and is checked at build time, so drift surfaces as a failed check instead of a surprise in an incident review. You can ask “which capabilities can write to production?” and get an answer from the system itself rather than from someone’s memory.

This composes with MCP rather than replacing it. MCP declares that a tool exists and how to call it. Capability declaration adds the governance metadata MCP deliberately leaves out — permissions, data class, blast radius — so the same tool definition carries both “how to use it” and “what it is allowed to touch.”

What is regulatory classification?

Regulatory classification tags each declared capability with the regimes it falls under — an EU AI Act risk tier, a HIPAA touchpoint, a GDPR data category, a SOC 2 control. The point is to make compliance a property of the system rather than a spreadsheet maintained alongside it.

The spreadsheet model breaks for the same reason prose policy does: it is a second copy of the truth that has to be kept in sync by hand, and it never is. When classification lives on the capability itself, a question like “show me every high-risk capability that processes personal data” becomes a query, not a quarter of an analyst’s week. And when a capability changes risk tier, the classification travels with it instead of waiting for someone to update a tab.

What is verifiable evidence — and why signed instead of logged?

Verifiable evidence means every consequential action emits a record you can check, not a record you are asked to believe. The mechanism is two pieces: a hash chain and a signature.

A plain log is mutable and trust-based. Anyone with write access can alter an entry, and nothing about the log proves it wasn’t altered — you are asserting its accuracy. A hash chain fixes the tampering problem: each entry includes a hash of the previous entry, so the records form a chain where every link commits to the one before it. Change any past entry and every hash after it breaks. Tampering stops being something you hope didn’t happen and becomes something the math reveals.

An ed25519 signature fixes the origin problem: the holder of a private key signs the exact bytes of the record, and anyone with the matching public key can verify that those exact bytes were signed by that key. No shared secret, no trusted third party — verification is a local computation. Together they convert “trust our audit log” into “verify it yourself,” which is the entire distance between asserted and verifiable.

This is the property we hold ourselves to: the deploys that carry this layer are signed and hash-chained, with the trail verifiable in the browser. A governance layer that cannot demonstrate its own claims is just more assertion.

How does this compose with MCP and CycloneDX?

It sits across them, not against them. MCP is a tool-calling protocol — it says “here is a capability and how to invoke it.” CycloneDX is a software bill of materials — it says “here is what went into this build.” Neither is a governance layer, and neither claims to be.

A governed control plane reads both and adds the layer above: capability declaration extends what MCP exposes, supply-chain evidence references what CycloneDX records, and the verifiable-evidence trail ties a given action back to the declared capability that performed it and the build it ran in. An open, machine-readable format is what lets these compose instead of collide — each standard keeps its job, and governance becomes the connective layer rather than a competing one.

What does a governed control plane look like in practice?

In practice it is unglamorous, which is the point. Capabilities ship with a declaration file checked in the same pull request as the code. The build fails if a capability touches regulated data without a classification. Every deploy and every consequential agent action writes a signed entry to a hash-chained trail. And the claims a system makes about itself — “this is compliant,” “this is what happened” — resolve to something a third party can verify without taking anyone’s word for it.

That is the whole thesis. A control plane decides and records by definition. A governed control plane makes those decisions declarable, those rules classifiable, and that record verifiable — so “our AI is safe and compliant” stops being a claim and starts being something you can check.

The teardown, in your inbox

One system at a time.

Email only. Mechanism teardowns when they ship — not on a schedule, no listicles. Unsubscribe anytime.