Are your agents contained by architecture, or only by policy?

Once you’ve decided what an agent is allowed to do, the next question is how that boundary is enforced. There are only two options: policy or architecture. Policy depends on compliance — the agent following its instructions. Architecture enforces the boundary whether or not anyone cooperates.

The difference shows up when things go wrong. If a prompt injection or bad dependency triggers something unexpected, what actually stops it from spreading? If the answer is “the agent’s instructions say not to,” that’s policy. If the answer is “the agent physically cannot reach anything outside its sandbox,” that’s architecture.

Docker sandboxes for coding agents illustrate the principle: the agent runs inside a microVM with its own kernel. Even if malicious code achieves a full breakout from its environment, it’s still inside a VM. The containment holds regardless of what the agent tries, because it’s structural, not behavioural.

The same test applies at every level of your stack. File access, network reach, API permissions, delegation authority — for each one, ask: if the agent ignores its instructions entirely, does the boundary still hold?

Go deeper: Your Coding Agent Needs a Sandbox compares native sandboxing, DevContainers, and Docker microVMs — and maps them to OWASP’s Top 10 for Agentic Applications.