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:
- What is this system allowed to do?, declared in a form a machine can read, not buried in a Confluence page.
- Under which rules does each capability fall?, every capability tagged to the regulatory regime it touches.
- 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.”
Deep dive: AI capability declaration, a manifest your build can check.
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.
Deep dive: classifying AI systems under the EU AI Act.
What is verifiable evidence, and why signed instead of logged?
Verifiable evidence gives a reviewer a specific recorded action to check. A hash chain and signature are useful parts of that mechanism, provided the action was captured and the key can be trusted.
Each hash-chain entry commits to the previous entry. Once a chain head is independently checkpointed, later edits to the recorded sequence are detectable. A chain by itself cannot show that no action was omitted or that a publisher did not replace the whole chain.
An ed25519 signature lets a reviewer check that the holder of the corresponding private key signed exact bytes. It does not identify that holder unless the public key is independently trusted. These checks make a particular record inspectable; they do not certify an entire runtime or release path.
This is the release bar we work toward: a signed, complete, checkpointed record tied to the deployed bytes. The site's browser check currently verifies a dated signed record and declaration hash with a same-site key; it does not prove the present deployment or protect against replacement of both site and key.
Deep dive: tamper-evident audit logs, why signed beats logged.
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?
A governed implementation would keep capability declarations with the code, reject unclassified regulated capabilities at build time, and capture consequential deployments and agent actions in a signed, checkpointed trail. Each route must actually run those controls before its evidence can support a claim. These are design criteria, not a claim that every Kinetic Gain deployment or runtime action currently has a signed record.
A control plane decides and records. A governed one makes its permissions, classifications, and decisions inspectable. Safety and compliance still depend on correct policies, complete capture, trusted keys, and independent review.