The Safest Place to Run a Coding Agent's Scripts on User Data

The safest place is a machine that exists for one run: a Firecracker microVM with its own guest kernel, created per session and destroyed after, with outbound traffic limited by an allowlist enforced on the host. Your agent's script reads the data it was sent to read. Everything else hits a wall.

Introduction

Your coding agent writes a script, points it at customer records, and runs it. The question is not whether the script works. It is where the script runs while it holds your users' data.

Most teams answer with whatever is nearby: a container in the app's cluster, a long-lived development box, a serverless function. Each shares something with the rest of your production system. When the code is untrusted and the data belongs to your users, a process boundary is not the boundary you want.

Key Takeaways

Code your agent wrote is untrusted code, even if your agent is trusted. The runtime needs a machine boundary, not a process boundary.
Containers share the host kernel. A Firecracker microVM gives each session its own guest kernel, so a bad script stays inside one disposable machine.
With user data in the machine, egress is the control that matters. Set an allowlist and enforcement sits in the host kernel with eBPF, outside the guest.
If the data cannot leave your boundary, bring your own compute: the same API runs on your machines, and the control plane and storage can be self-hosted.
New accounts start with 500 free credits, billing is per second, and egress is $0.

Why a Disposable MicroVM Is the Safest Place for Agent-Written Code

Walk the candidate places and the tradeoffs are concrete.

Your app's own runtime or a shared container is the default choice and the weakest. Containers isolate processes on a shared host kernel, and hostile or manipulated code looks for exactly that shared surface. Our analysis of a sandbox escape in an AI agent shows how shared-kernel isolation fails. One escape and the script is next to your data.

A long-lived VM or a developer box draws a harder boundary and fails on time. State accumulates: packages installed, credentials cached, yesterday's run still resident. A compromised session contaminates every session after it, and slow provisioning pushes teams to batch runs onto one machine.

Serverless functions are short-lived but run inside your account's trust zone on a network path you do not control.

A microVM per session inverts each failure. The machine has its own guest kernel, so the boundary is the machine, not a process. It exists for one run and is destroyed after, so nothing accumulates. The network path is a policy you set, enforced from outside the machine. For data workloads the pattern is simple: the model writes the query, the sandbox runs it, and your app never touches the data.

The objection is that a machine per run sounds heavy. A paused sandbox restores in tens of milliseconds, about 30 ms on an idle host, though that is an idle-host figure, not an SLA. Pausing takes about 1.4 seconds and stops the meter.

What Keeps a Script With User Data Contained

Two controls do the work: the machine boundary and the egress policy.

A kernel per session. Every CreateOS Sandbox is a Firecracker microVM with its own guest kernel. It is not a container. Isolation sits at the machine boundary, which is what a kernel-level escape runs into.

Egress you set, enforced outside the guest. Outbound access is open until you set at least one rule. Once set, everything else is denied. Rules take a host, host:port, wildcard subdomains, IPs and CIDRs, plus domain rules through a transparent proxy. Enforcement sits in the host kernel with eBPF, outside the VM, so code inside cannot rewrite or route around it, and the rules survive a full guest compromise. Inbound is closed by default regardless. Set them in the egress field at create time, update them live through PUT /v1/sandboxes/{id}/egress, or use the SDK's setEgress method or the CLI's createos sandbox firewall set command.

Fork for parallel runs. Forking a paused sandbox branches its memory and disk state. Run several variants of a data job side by side and keep the one whose output checks out, each on its own machine.

Bring your own everything. The same API runs on customer machines, object storage can be your own S3, R2, or MinIO, and the control plane and storage can be self-hosted entirely. When user data cannot leave your boundary, it does not have to.

What We Already Run on Sandboxes

The isolation argument should not rest on promises. CreateOS has run its own CI on sandboxes since July 2026, including its GitHub Actions runner and a coding-agent plugin. 2.6 million sandboxes have been created since June 2026. Uptime is 99%+. NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023.

We also say what is young. The Sandbox surface is a young product, and compliance certifications are on the roadmap for it, not shipped. What is proven today is the isolation model, the egress enforcement, and our own daily use of both.

What to Check Before You Move Agent Execution Out of Your App

Whether you need a per-run machine at all. If your team only ever runs code it wrote and reviewed, a sandbox is extra machinery. The moment the code comes from a model, the calculus changes.

The egress default. Outbound access is open until you set a rule. Make the allowlist part of session creation, not a cleanup task. A sandbox holding user data with no egress rules is a machine you have not finished configuring.

Where the data may sit. If residency rules keep user data inside your cloud, use bring-your-own compute or self-host. The API is the same either way.

The shapes you need. Sandboxes run from a quarter CPU up to 8 CPUs and 16 GB of memory, with 10 to 60 GB of disk. There are no GPU sandboxes.

The wiring. An SDK (@nodeops-createos/sandbox on npm), a CLI (createos sandbox), and MCP cover the integration, and the docs include the pages an agent harness needs. For the variant where the sandbox holds the database credentials your agent never sees, read our post on keeping production database credentials away from a query-writing agent.

Frequently Asked Questions

Is a container not enough for code my agent wrote?

A container isolates processes on a shared host kernel. Code written by a model is exactly the kind of workload that probes that shared surface, and our sandbox escape analysis walks through how it fails. A Firecracker microVM boots its own guest kernel, so a kernel-level escape lands in a machine built for one run, then destroyed.

What stops a script from sending user data somewhere else?

The egress allowlist. Outbound access is open until you set at least one rule. Once set, everything else is denied. Enforcement sits in the host kernel with eBPF, outside the guest, so the script cannot rewrite or route around it. Inbound is closed by default either way.

Can the sandbox run inside our own cloud account?

Yes. Bring-your-own compute runs the same API on your machines, and you can self-host the control plane and storage. Object storage works with your own S3, R2, or MinIO.

What does it cost to test on a real workload?

Billing is per second, egress is $0, and pausing a sandbox stops the meter. New accounts start with 500 free credits. Published unit rates are on the Sandbox pricing page.

Conclusion

A coding agent that executes scripts on user data is a permanent part of your product, not a demo. The safest place for its code is a machine with one job: hold the data for one run, reach only what you allow, and disappear when the run ends. CreateOS Sandbox is that machine, with egress enforced outside the guest and bring-your-own options that keep data inside your boundary. Start free with 500 credits at createos.sh/products/sandbox.

About CreateOS

CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.