Sandboxing Is Not Governance
Docker solves the infrastructure layer. Nobody has solved the semantic layer. Yet.
Docker AI Governance ships container-level sandboxing for agents — network access controls, filesystem isolation, and MCP policy enforcement at the infrastructure boundary. It's a real product solving a real problem. Applaud it.
But here's what it doesn't catch, and what nobody in the room seems to be saying clearly:
A properly sandboxed agent can still be catastrophically wrong.
The Layer That Matters
Sandboxing answers the question: where does the agent run, and what can it touch at the OS level?
That's necessary. It is not sufficient.
The harder question is: what does the agent decide to do, and is that decision policy-compliant at the semantic level?
An agent operating inside a perfectly-scoped container, with correct network egress rules, with filesystem mounts audited — can still:
- Call a production API with a destructively-scoped query
- Exfiltrate sensitive data through a fully-permitted tool call
- Chain tool invocations into an outcome no policy document ever intended to permit
- Make a semantically wrong but syntactically valid request that passes every infrastructure check on the way out
The sandbox catches where the agent runs. It doesn't catch what the agent meant, or whether the request it's about to fire respects your data classification policy, your customer data handling obligations, or your internal access controls.
The Two Layers You Actually Need
| Layer | What it catches | What it misses |
|---|---|---|
| Infrastructure (sandbox) | Egress, filesystem access, process isolation | Semantically wrong but permitted requests |
| Request / tool-call policy | Intent, scope, tool-chain logic, semantic compliance | Nothing — if it's built correctly |
These are not competing products. They are complementary controls at different abstraction levels. You need both. Today, the industry has deployed one.
What Request-Layer Governance Looks Like
Policy evaluated at the moment an agent constructs a tool call — before execution — against a ruleset that understands:
- What data is being accessed or modified
- What the inferred intent of the action is
- Whether the action is within the agent's authorized scope for this session
- Whether the tool chain, taken as a sequence, produces a permitted outcome
This is not network filtering. This is not a sandbox. This is a policy engine that operates on requests and their semantics, not on packets and file descriptors.
This is what Klyo is building.
The Takeaway
Docker AI Governance is a good product. Ship it. Run it. But don't confuse infrastructure controls with agent governance. The wall around the container doesn't know what the agent decided. The request layer does.
Both layers are needed. One exists. We're building the other.
Klyo is an AI security gateway for enterprise agent deployments. Early access → klyo.com
