Running Agent-Generated Code Without a Shared Cloud: A Decision Guide to Self-Hosted Isolation

If your company is regulated, the question is not whether agents should write code. It is where that code runs. Sending it to a shared, multi-tenant cloud is off the table, so the real decision is which execution model keeps the code inside your perimeter while still giving agents a place to work. This guide walks through the options and the criteria that separate them.

Introduction

Regulated teams usually arrive here from one of two directions. A security review has blocked an agent proof of concept because the proposed runtime sends generated code to a vendor cloud. Or a data-residency rule says code, prompts, and working files cannot leave infrastructure you control.

Both point to the same requirement: isolated execution on your own infrastructure. The options are not all equivalent. They differ in isolation strength, in who enforces network policy, and in how much of the stack you end up operating. The choice matters more than the agent framework choice, because the runtime is what a regulator will ask about.

CreateOS builds for this constraint. CreateOS Sandbox runs untrusted or agent-written code in a Firecracker microVM, and the same API runs on customer machines when sessions must stay inside your boundary. The rest of this piece is a decision guide, not a pitch: the criteria below apply to any approach you evaluate.

Key Takeaways

Four execution models exist for agent-generated code on your own infrastructure: shared containers on your Kubernetes cluster, dedicated VMs, Firecracker microVMs, and a managed self-hosted sandbox platform.
Container isolation shares a kernel with the host. For code an agent wrote and nobody reviewed, that is a weaker boundary than most security teams will accept.
Firecracker microVMs give each session its own guest kernel, which is the isolation boundary regulators and security reviews tend to ask about.
Self-hosting a sandbox platform removes the shared-cloud problem but adds an operational bill. Check what the vendor lets you bring: your own compute, your own storage, your own network policy.
Egress control is a separate decision from isolation. Isolation contains what code can do to the machine; egress policy controls what it can reach. You need both, and they are enforced in different places.

Decision criteria

Evaluate any option against five criteria.

1. Isolation boundary. What separates one session from the host and from other sessions? Containers share the host kernel. A microVM has its own kernel, so a kernel-level escape from the guest does not reach the host. For code your team wrote and reviewed, a container is often fine. For code an agent generated minutes ago, the boundary should be a machine boundary.

2. Data path. Where do code, prompts, environment variables, and working files physically live? An option that keeps compute on your infrastructure but replicates state to a vendor cloud does not solve the problem. Look for zero data retention by default and storage you control.

3. Egress governance. Outbound network access is where most agent risk actually lives: exfiltration, callbacks, unexpected API calls. Ask where the egress policy is enforced. A rule enforced inside the guest can be rewritten by the code it governs. Enforcement in the host kernel, outside the VM, survives a full guest compromise. One caution on defaults: with CreateOS Sandbox, outbound access is open until you set at least one rule; once set, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest. Inbound is closed by default regardless.

4. Operational burden. Self-hosted means someone runs it. Count the components: control plane, storage, image builds, upgrades, incident response. A platform you deploy into your VPC or data centre shifts most of that burden to the vendor. Raw Firecracker on your own Kubernetes cluster puts all of it on your team.

5. Auditability. A regulator will ask what each agent did. Execution records, traces, and an audit trail need to exist on your side of the perimeter, not in a vendor dashboard you cannot export.

How to choose

If your agents only run code your own team wrote and reviewed, a shared container pool on your existing cluster is a reasonable answer. You already operate Kubernetes. The isolation tradeoff is acceptable because the code is trusted. This is the cheapest option and the fastest to approve internally.

If agents generate code that runs without human review, containers are the wrong boundary. Move to per-session VMs or microVMs. A dedicated VM per session works but is slow to provision and expensive at agent scale. A Firecracker microVM gives the machine boundary with startup fast enough for interactive agent loops: creation restores from snapshot in tens of milliseconds, about 30 ms on an idle host, an idle-host figure, not an SLA, as our runtime guide states it.

If the blocker is the shared cloud itself, not the technology, look for a self-hosted sandbox platform rather than building on raw Firecracker. CreateOS Sandbox supports bring-your-own compute: the same API and isolation run on machines inside your cloud or data centre, so code never leaves your perimeter. You bring your own S3-compatible storage as well (customer S3, R2, or MinIO), and the control plane and storage can be self-hosted entirely when code cannot leave the boundary. The tradeoff is real: you take on deployment and upgrade work a vendor-hosted service would absorb. What you get in exchange is a runtime your security team can inspect.

If your regulator requires proof, not just architecture, prioritize options with an audit trail of what each agent did, plus certifications you can verify. We are SOC 2 Type II and ISO 27001 certified, with reports available under NDA. Ask any vendor the same question and read the report, not the badge.

If your agents need to talk to each other, check networking between sessions. Isolated machines that cannot find each other force traffic through public endpoints, which recreates the exposure you were trying to remove. Private overlay networks with per-network DNS keep agent-to-agent traffic inside your perimeter.

A practical sequence: start with the data-path question, because it eliminates options fastest. Then test the egress model, because that is where agent-specific risk concentrates. Then price the operational burden, including the on-call rotation.

Frequently Asked Questions

Is a container not enough isolation for agent-generated code? Containers share the host kernel with the host and with each other. For reviewed, trusted code that is a normal tradeoff. For code an agent wrote and nobody has read, a kernel shared with your infrastructure is the weak point. A microVM with its own guest kernel is the stronger boundary, and it is the one most security reviews ask for.

What does self-hosting a sandbox platform actually involve? You deploy the control plane and storage into your own VPC or data centre and the vendor's software runs there. With CreateOS Sandbox you can bring your own compute and your own S3-compatible storage, so sessions run on machines you own. The operational work is deployment, upgrades, and capacity planning; the vendor carries the isolation and egress enforcement logic.

How do I stop generated code from calling external services? Set an egress allowlist on the sandbox. In CreateOS Sandbox you set it at create time through the egress field, live via PUT /v1/sandboxes/{id}/egress, through the SDK's setEgress method, or with the CLI's createos sandbox firewall set command. Rules take hosts, ports, wildcard subdomains, IPs, and CIDRs. Once one rule exists, everything else is denied, and the enforcement sits in the host kernel with eBPF, outside the guest, so code inside cannot rewrite it. Details are in the CreateOS docs.

Does self-hosted mean we lose the managed experience? You lose the part where a vendor operates the compute, and you keep the part that matters for agents: the same API, the same isolation, the same egress enforcement, and the same audit trail. You trade some operational convenience for a data path your regulator can sign off on. For most regulated teams that trade is the whole point.

Conclusion

The shared cloud is not the only place agent-generated code can run. The decision comes down to the isolation boundary, the data path, where egress is enforced, and who operates the result. Teams running only reviewed code can stay on containers. Teams running unreviewed agent output inside a regulated perimeter should move to microVM isolation on infrastructure they control, with egress policy enforced outside the guest and an audit trail on their side of the line.

If that describes your situation, start with the CreateOS Sandbox architecture overview or talk to us about a self-hosted deployment designed around your compliance requirements.

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.