3 posts tagged with "sandboxing"

If you run coding agents at any real scale, you own a fleet of ephemeral virtual machines. You may not have signed up for that. It happened the moment you decided — correctly — that untrusted, model-generated code should never execute inside your application's trust boundary. Every task gets its own sandbox, every sandbox is a microVM or hardened container, and suddenly the platform team that thought it was building "an agent product" is operating something that looks suspiciously like a miniature AWS Lambda: pool warming, snapshot pipelines, bin-packing schedulers, and a reaper process for the environments nobody came back for.

The trap is assuming your container orchestration instincts transfer cleanly. Some do. But Kubernetes grew up scheduling long-lived, homogeneous services, and agent sandboxes are the opposite: short-lived, wildly heterogeneous, and created at rates that make a deployment rollout look leisurely. The teams that struggle are the ones that treat sandbox infrastructure as "just containers with extra steps." The interesting engineering — and almost all of the cost — lives in four problems: cold starts, filesystem state, packing density, and abandonment.

Your own stack has three environments. Dev is disposable, staging is production-shaped, and prod is sacred. Twenty years of engineering culture — CI gates, canary deploys, blue-green rollouts — all rest on that tiering. Then you give an agent a tool that calls Salesforce, QuickBooks, or Gmail, and the tiering silently evaporates. There is no staging Salesforce for your customer's org. There is no shadow copy of the invoice ledger. The moment a tool call crosses your network boundary into a third-party SaaS, there is exactly one environment, and it is production.

This is the least discussed gap in agent engineering. We have gotten good at sandboxing the agent's compute — containers, egress allowlists, resource caps. We have gotten passable at evaluating the agent's reasoning — offline evals, LLM-as-judge, trajectory scoring. But the agent's actions on the outside world still run against live systems holding real customer data, because for most SaaS surfaces nothing else exists. Teams quietly resolve this the only two ways they can: test against production, or don't test at all.

Most teams shipping LLM agents with code execution capabilities make the same miscalculation: they treat sandboxing as a binary property. Either they skip isolation entirely ("we trust our users") or they deploy Docker containers and consider the problem solved. Neither position survives contact with production.

The reality is that sandboxing exists on a spectrum with five distinct levels, each offering a different isolation guarantee, performance profile, and operational cost. The mismatch between chosen isolation level and actual risk profile is the root cause of most agent security incidents — not the absence of any sandbox at all.