Why AI Coding Agents Need a VM-Grade Boundary, Not Just a Container

The share of unattended code is going up

Sonar's 2026 State of Code Developer Survey put AI-generated or AI-assisted code at 42% of what respondents committed, with teams projecting that share to climb to 65% by 2027. Numbers like that describe a shift most engineering teams can already feel: an agent isn't just autocompleting a line anymore, it's writing a function, installing a dependency to support it, running the test suite, and iterating — largely without a human reading every intermediate step.

That shift is exactly what's pushing cloud-native infrastructure providers toward wrapping agent execution in VM-grade isolation instead of a plain container. It's worth being specific about why a boundary that was good enough for CI jobs and build pipelines for a decade suddenly isn't good enough for agents.

Containers assume a known, static workload

A standard container's security model is not really built to stop a well-informed, actively adapting process from probing its way around it. Container isolation (namespaces, cgroups, a shared kernel) is good at cost and density, and good at containing a workload that behaves the way its authors expected. It was never designed as a hard boundary against a process that can read documentation, notice a misconfiguration, and decide to try installing something outside its expected footprint.

That's a fair description of what an autonomous coding agent does by nature. It runs commands it wasn't explicitly told to run, installs packages that weren't pre-approved, and reads files to figure out what's around it — because those are also exactly the behaviors that make it useful. The same adaptability that lets an agent debug its way out of a broken build is what makes "trust the container boundary" a weaker assumption than it used to be.

What VM-grade actually adds

The shift underway isn't about distrust of any specific agent — it's about matching the isolation boundary to what the workload can now do on its own. A VM-grade boundary (a real hypervisor-backed sandbox, or a microVM approach like Firecracker) gives you:

• A separate kernel per workload, closing the shared-kernel escape paths that container isolation was never meant to fully close.
• Resource and network boundaries that don't depend on the workload behaving. A container's cgroup limits are cooperative in spirit even when enforced by the kernel; a VM boundary doesn't need the workload to be well-behaved to hold.
• A blast radius that stops at the sandbox, which matters specifically because an agent's actions — package installs, shell commands, file writes — are dynamic and only fully known after the fact, not declared upfront the way a CI job's steps usually are.

What this looks like in a real setup

A pattern we'd recommend to a client running agent-driven code generation or agent-driven build steps today:

# conceptual sandbox policy for an agent execution step
sandbox:
  isolation: microvm       # hypervisor-backed, not shared-kernel
  network:
    egress: allowlist      # package registries only, no arbitrary outbound
  filesystem:
    scope: ephemeral        # workspace destroyed after the task
  resource_limits:
    cpu: "2"
    memory: "4Gi"
    timeout: "15m"
  audit:
    log_commands: true
    log_network: true

The specific YAML above is illustrative, not a product spec — the point is the shape of the policy: strict egress, ephemeral filesystem, hard resource caps, and full command/network logging, all assumed necessary rather than added after an incident. The CNCF's push toward a Certified Kubernetes AI Conformance Program points in the same direction — standardizing how AI/ML and, increasingly, agentic workloads should be run inside cluster infrastructure rather than leaving each team to improvise its own boundary.

Where this matters for real teams

For most engineering organizations, the practical question isn't whether to allow agents to install packages or run shell commands — that ability is most of the value. The question is where those actions are allowed to happen, and how far a mistake or a genuinely malicious package can travel from there.

A few concrete recommendations:

1. Never run agent-driven builds inside infrastructure that also holds production credentials. If an agent's sandbox and your deploy pipeline's secrets share a boundary, you've defeated the sandbox.
2. Log at the command and network level, not just at the task level. "The agent ran a build" is not useful after the fact; "the agent ran pip install X, then made three outbound calls to Y" is.
3. Treat package installation as the highest-risk action an agent takes, not routine housekeeping. A supply-chain issue introduced by an agent installing an unreviewed dependency is functionally identical to one a human introduced, and needs the same review gate.

Our take

Container isolation was built for workloads whose behavior was mostly known ahead of time. Agentic workloads break that assumption by design — the value of an agent is precisely that it can decide what to run next based on what it just found. Infrastructure that wraps agents in the same isolation model built for deterministic CI jobs is trusting a boundary that was never designed to hold against that kind of adaptability.

We'd treat the current move toward VM-grade sandboxing for agents not as an optional hardening step but as the baseline configuration for any environment where an agent installs its own dependencies or runs commands it wasn't explicitly scripted to run. The convenience of agentic coding is real; so is the fact that it changes what your isolation boundary needs to be able to stop.

Reference: Latest DevOps & Cloud News – 10 September 2026