AI control planes are having a moment. The term has moved fast — from niche infrastructure vocabulary to standard positioning language in the span of about eighteen months. Which means it now covers a lot of very different things.
Some tools called AI control planes are governance and observability layers: they track what agents are doing, log decisions, measure cost, and flag anomalies. That's useful work. But it's work that assumes your agents are already running somewhere secure. The governance layer sits on top. What's underneath is someone else's problem.
For teams moving AI into production at the enterprise level, that separation creates a problem you can't audit your way out of.
When an AI agent executes, it runs somewhere. It has access to compute, to memory, to network. It can make outbound requests, read data, spawn other agents. The security posture of that execution environment determines what an agent can actually do — and what it can be made to do.
A governance tool that logs what an agent did does not change what the agent was able to do. If the execution environment has no network isolation, logging the outbound request doesn't undo it. If there's no sandboxing between tenants, an audit trail records the exposure without preventing it.
This is the gap: compliance at the observability layer is not the same as security at the infrastructure layer. Enterprise teams have learned this distinction in every other domain. It applies here too.
An AI control plane that operates at the infrastructure level controls the environment where agents run, not just what gets reported afterward. That means:
The distinction matters most when something goes wrong. An incident that originates in a properly isolated execution environment is contained. The same incident in a shared, insufficiently isolated environment is a breach.
Single-agent systems are relatively easy to govern after the fact. Multi-agent systems — where agents spawn other agents, pass context between them, and operate autonomously across longer time horizons — make the governance-first approach increasingly brittle.
The attack surface grows. The number of outbound actions multiplies. The dependencies between agents mean that a compromise in one can propagate through the chain. Governance tools observe this; they don't constrain it.
At scale, the control plane isn't just a management interface. It's the environment itself.
Crafting is built from the infrastructure up. Secure, networked execution environments are the foundation — not a feature layered on afterward. Agents run in isolated sandboxes with explicit network controls. Multi-agent orchestration operates at the platform level. SOC 2 Type II certification reflects the design of the underlying infrastructure, not a compliance exercise on top of it.
If you're evaluating AI control plane tooling, the question worth asking is: where does control actually start? At the log, or at the environment?
