When we plotted the AI tools market on the ten axes of the AI capability map, most of the result was unsurprising. Gateways cluster on policy control. Observability platforms own tracing. Governance suites own documentation. Security tools own detection.
But two spokes stay close to empty across every category: agent containment and deployment sovereignty.
That emptiness is not a market gap waiting for a startup. It is a structural fact about what point tools can and cannot be — and it decides whether autonomous AI is deployable at all in a regulated enterprise.
Why nobody sells containment
Every category on the map interacts with AI systems from the outside. A gateway sees the calls an agent makes through it. An observability platform sees the traces an agent emits. A security scanner sees the artifacts an agent exposes. An agent "control tower" sees the fleet — registrations, postures, policies.
Containment is different in kind: it is a claim about what an agent cannot do, and you cannot enforce a cannot from the outside. An agent that acts — writes to systems of record, calls tools, moves money, files tickets — has to be contained where it runs, at the runtime boundary, or it is not contained at all.
That is why the spoke is empty. Enforcing a runtime boundary means owning the runtime: kernel-level isolation, credentials that exist only for the duration of a task, egress that physically cannot bypass the policy plane, and a kill switch that stops the process rather than politely revoking a token. A SaaS point tool cannot ship that, because it does not run your workloads. It can only watch them.
This is what Kosmoy's Action Capsule is: a Kubernetes-native sandbox around an agent, private model or MCP server, whose only egress is the paired gateway. Pre-flight authorization, execution leases, just-in-time credentials, mediated actions, kill switch — enforced at the boundary, not requested of the agent.
The test for any containment claim is simple: if the agent's code is compromised or simply wrong, does the control still hold? Guardrails in a prompt do not survive that test. A registry entry does not survive it. A runtime boundary does.
Why nobody sells sovereignty
The second empty spoke has a more ironic explanation: deployment sovereignty is the one capability a SaaS product cannot sell, because the product itself is the violation.
Consider what the control plane for enterprise AI actually holds: every prompt and response, agent traces, cost by team, the risk register, guardrail decisions, audit evidence. If that control plane is a multi-tenant SaaS, then the most sensitive operational dataset your AI programme produces — the record of everything your AI did — lives in someone else's cloud, under someone else's jurisdiction, on someone else's uptime.
For a bank supervised under DORA, a defence contractor with air-gapped networks, or a hospital moving clinical data, that is not a procurement preference. It is disqualifying.
Hyperscaler AI studios score broadly on the map — building, observability, some governance — but sovereignty is their structural floor: the studio is the cloud. Multi-cloud and on-prem estates fall outside it by definition, and the management layer for AI that runs everywhere cannot live inside one provider.
Sovereignty, like containment, has to be a property of the architecture: single-tenant software, deployed in the customer's own Kubernetes — any cloud or none — with prompts, logs and evidence never transiting a vendor's infrastructure. Air-gap capable, because for some estates the network boundary is the control.
Two spokes, one buyer's question
Here is the practical way to use this. When you evaluate any AI governance stack — one platform or five point tools — ask two questions the vendor decks tend to skip:
"When an agent misbehaves, what physically stops it?" Not what alerts, not what logs — what stops it. If the answer is a revoked API key and a hope that the agent honors it, the containment spoke of your stack is empty.
"Where does the record of everything our AI did live?" If the answer is a vendor's cloud, your sovereignty spoke is empty — and it will stay empty no matter how many more tools you add, because every tool you add is another place the record lives.
Most stacks assembled from point categories fail both questions. Not because the tools are bad, but because both capabilities require owning the runtime and the deployment — and point tools, by design, own neither.
Containment is a lifecycle step, not a feature
One last framing. On the AI operating loop, deployment and containment are step 04 — after a system is registered, classified, assessed and tested, and before guardrails and observation take over in production. Containment is not a bolt-on for the scary agents; it is the default posture for anything that acts.
The agents that only answer route through the gateway. The agents that act run in a capsule. Both leave the same evidence in the same audit trail — and that, not any single feature, is what the two empty spokes look like when they are filled.
Frequently asked questions
How do you contain an AI agent?
At the runtime boundary, not in the prompt. Containment means kernel-level isolation, credentials that exist only for the duration of a task, egress that physically cannot bypass the policy plane, and a kill switch that stops the process. The test: if the agent is compromised or simply wrong, does the control still hold?
What is AI deployment sovereignty?
Sovereignty means the control plane — every prompt, trace, cost record, risk register entry and audit log — runs inside your own infrastructure and jurisdiction. A multi-tenant SaaS control tool cannot sell it, because the product itself is where the data would go.
Why do no AI security tools offer agent sandboxing?
Because every point category interacts with agents from the outside: a gateway sees calls routed through it, an observability tool sees emitted traces, a control tower sees registrations. Enforcing what an agent cannot do requires owning the runtime, which a SaaS tool does not.