AI Coding Agents Need Walls, Not Just Wings

The failure mode nobody talks about in AI coding agents is not hallucination. It is boundary collapse. When you hand an agent write access to a filesystem, a shell, and a network connection, you have not built a productivity tool. You have built an autonomous process with blast radius proportional to its permissions. The infrastructure conversation around coding agents has been dominated by capability questions: which model, which context window, which tool use API. The harder engineering question is containment: what does the agent touch, and how do you bound that surface without breaking the agent's ability to do useful work?

Two pieces of infrastructure shipped this week that address this problem from opposite angles, and together they sketch something close to a complete systems architecture for production coding agents.

The Execution Boundary Problem

Docker Sandboxes introduces microVM-based isolation for coding agents like Claude Code, Codex, and Cursor. The distinction between a container and a microVM matters here. A container shares the host kernel. A microVM runs a full lightweight kernel inside a virtualization boundary, which means a compromised agent process cannot escape to the host via kernel exploits. This is the same threat model that Firecracker (AWS Lambda's underlying isolation layer) was designed for.

The Sandboxes CLI manages the lifecycle of these environments and, more critically, manages network policy as a first-class configuration concern. Three policy tiers are exposed: Locked Down, Balanced, and Open.

Network Policy Is the Real Security Surface

The Balanced policy is where the practical engineering lives. It allows outbound access to AI provider APIs (the agent needs to make inference calls), package manager registries (npm, PyPI, cargo), code hosts (GitHub, GitLab), container registries, and common cloud service endpoints. This is not arbitrary permissiveness. It is a curated allowlist that covers the actual dependency graph of a working coding agent without punching a hole to the open internet.

The Locked Down policy blocks all outbound by default. The Open policy is what you use in a throwaway dev environment when you want zero friction and accept the risk. The ability to extend the Balanced policy with custom domain allowlists is where teams running internal package registries or private artifact stores will find the most operational value.

Credentials Belong Outside The Agent's Mind

Authentication credential injection for agent identity is also handled at the CLI layer, which is architecturally correct. Credentials should never live in the agent's context window or in tool call parameters. Injecting them at the environment boundary, before the agent process starts, keeps them outside the model's attention mechanism entirely.

The practical question for teams evaluating this: microVM boot latency is real. Firecracker achieves sub-second cold starts at scale, but sandbox orchestration overhead compounds when you are running parallel agents across a large monorepo. Docker has not published benchmarks on Sandboxes boot times or concurrent sandbox density. Those numbers matter before you commit this to a CI pipeline.

The Comprehension Boundary Problem

Carto attacks the other wall. Once you have a secure execution environment, you still need the agent to navigate a large codebase without destroying its own context or making structurally incoherent edits.

The failure modes Carto targets are specific and verifiable by anyone who has run Claude Code or Codex against a 50,000-line codebase. Tool thrashing is the pattern where the agent repeatedly calls file read and search tools in loops because it cannot maintain a stable model of the codebase structure between steps. Context overflow is what happens when the agent stuffs too many files into its context window to compensate for not having structural understanding, eventually exceeding the token limit or degrading generation quality as attention dilutes. Incorrect file selection is the agent editing the wrong module because it resolved a name by surface similarity rather than actual dependency topology.

Structural Intelligence Is a Retrieval Architecture

The Domain Map that Carto generates automatically is, mechanically, a structured index of the codebase's module boundaries, ownership topology, and inter-module dependency graph. This is not a RAG retrieval store over file content. It is a graph-structured representation of the codebase's architecture, generated statically from the code itself without requiring developer annotation.

The "blast radius" feature deserves precise description. Given a planned edit to a specific module or file, blast radius analysis traverses the dependency graph to surface which other modules are likely affected. This is standard static analysis territory: identify callers, identify dependents, identify shared state. What makes it relevant to agent workflows is where it sits in the execution loop. If blast radius analysis runs before the agent begins editing, it can be injected into the agent's context as a structured pre-computation, which replaces the agent's need to discover this topology through repeated tool calls.

Precomputed Structure Frees Agents For Real Work

This is the architectural insight: precomputed structural intelligence reduces the agent's tool call budget for orientation tasks, reserving that budget for actual generation and editing. A ReAct-pattern agent that would spend eight tool calls mapping a module's dependencies before editing it can instead receive that map as a single context injection at the start of the task.

The agent's context window is not a workspace. It is a scarce resource. Anything you can precompute outside the loop is tool call budget you return to the agent for actual work.

Carto is open source, which means the Domain Map generation logic is auditable. The blast radius analysis quality will depend entirely on the static analysis correctness for a given language ecosystem. Python's dynamic import patterns, for instance, are notoriously difficult to resolve statically. The claim that Carto works without configuration is plausible for well-structured TypeScript or Go codebases. For Python projects with heavy use of importlib or plugin architectures, that claim warrants testing before trust.

What a Complete Architecture Looks Like

These two tools address orthogonal problems but compose naturally. The microVM boundary handles execution security and network policy. The structural intelligence layer handles codebase comprehension and context efficiency. Neither solves the other's problem, and neither is sufficient alone.

The Gap Neither Tool Fills

What is still missing from this stack: agent observability at the tool call level. When a coding agent running inside a Sandboxes microVM begins thrashing on file reads despite having a Carto Domain Map available, you need a trace that shows you exactly which tool calls were made, in what order, against which files, with what results. The security layer tells you what the agent was allowed to touch. The structural layer tells you what it should have touched. The observability layer tells you what it actually did.

Without that third layer, debugging a misbehaving coding agent in production is still archaeology. You have logs, you have diffs, and you have a model that cannot explain its own decisions across a multi-step execution trace. That problem is not solved by either Docker Sandboxes or Carto, and it is the one that will bite you at 3am when an agent deletes the wrong migration file.

Sources: DEV.to (June 3, 2026), NewsAPI (June 3, 2026)