Keeping Agent-Generated Code Inside Your Perimeter: Self-Hosted Isolation Options Explained

If your compliance regime forbids sending agent-generated code to a shared cloud, you have three practical options: run that code in isolated micro-VMs on infrastructure you control, self-host the full execution stack inside your own VPC or data centre, or keep the code on your side while only the model calls leave. The first two are what CreateOS Sandbox is built for: every session gets a Firecracker microVM with its own guest kernel, and the same API runs on our cloud or on your machines.

Introduction

Regulated teams face a specific version of the agent infrastructure problem. Your coding agents write code that nobody on your team has reviewed. That code needs a machine to run on. And the machine cannot be a shared, multi-tenant cloud service, because the code may contain customer data, source under NDA, or anything else your auditors have scoped to your boundary.

The usual answer, "just run it in a container," does not survive a security review. Containers share the host kernel. A determined payload can escape a container, and agent-generated code is exactly the kind of payload you should assume is hostile until proven otherwise. This piece walks through what isolated execution on your own infrastructure actually requires, what your options are, and where a governed sandbox fits.

Key Takeaways

Agent-generated code is untrusted code. It needs machine-boundary isolation, not a namespace.
Self-hosting is a spectrum: bring your own compute for the sandboxes, or self-host the control plane and storage entirely when code cannot leave your boundary at all.
Egress governance matters as much as isolation. 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.
Data residency is a deployment decision, not a policy document. The same API should work whether the machine is ours or yours.

Why Containers Are Not Enough for Code You Did Not Write

A container gives you process isolation on a shared kernel. For code your own team wrote and reviewed, that is often a reasonable tradeoff. For code an agent wrote five seconds ago, it is not.

A Firecracker microVM is a different primitive. Every sandbox gets its own guest kernel, so isolation happens at the machine boundary. Code inside cannot see the host kernel, cannot reach another tenant's machine, and cannot rewrite the network rules that govern it. When your security reviewer asks "what holds this code if it turns hostile," the answer is a virtual machine, not a namespace.

This is the distinction to lead with internally. The question is not "is the container configured tightly." The question is "is the execution boundary a kernel we share with the workload."

Your Three Options for Isolated Execution on Your Own Infrastructure

Option 1: Bring your own compute

The lightest path keeps the sandbox API you would use in any cloud, but points it at machines inside your own perimeter. CreateOS Sandbox supports bring-your-own compute: the same API runs on customer machines, so your agents create, pause, resume, and fork sandboxes exactly as they would anywhere else, while the microVMs themselves live on hardware you control.

What this gets you: agent-generated code never executes outside your boundary, and your network team keeps the perimeter rules. What it does not get you: a zero-touch deployment. Your platform team owns the hosts, and you coordinate with us on provisioning.

Option 2: Self-host the control plane and storage

Some regulated environments go further. If the code, the artifacts, and the session state all have to stay inside the boundary, bring-your-own compute is not enough. CreateOS Sandbox can be self-hosted entirely: control plane and storage run inside your environment, so nothing about a session leaves your infrastructure.

This is the right topology when a data-residency mandate or a sovereignty requirement makes any external dependency a non-starter. The tradeoff is operational weight. You run more of the stack, and upgrades and capacity planning sit with your team. For teams already operating their own Kubernetes estate, that tradeoff is often acceptable. For small teams, it usually is not.

Option 3: Keep storage on your side, execution flexible

A middle path: bring your own bucket. Point the sandbox layer at your own S3, R2, or MinIO-compatible storage, so snapshots, artifacts, and session data land in storage you govern, while the compute topology stays flexible. This suits teams whose hard constraint is data location rather than compute location.

Egress Governance: The Half of Isolation Everyone Forgets

Isolation keeps hostile code in. Egress governance keeps it from calling out. Both matter, and they are different controls.

Get the default right in your head: outbound access is open until you set at least one rule. Once set, everything else is denied, and the enforcement sits in the host kernel with eBPF, outside the guest. Code inside the VM cannot rewrite or route around it. Inbound is closed by default regardless.

You set the allowlist through the egress field at sandbox create time, a live update through the API, the SDK's setEgress method, or the CLI. Rules take hosts, host:port pairs, wildcard subdomains, IPs, and CIDRs. For a regulated team, this is the control your security reviewer will actually test: can the workload reach only the systems you named, and does that hold if the guest is fully compromised.

What a Deployment Conversation Should Cover

If you are evaluating this category, the questions that separate vendors are concrete:

Where does the execution boundary sit: shared kernel or per-session guest kernel?
Can the same API run on our cloud, your VPC, and your own machines, or does self-hosting mean a different product?
Where is egress enforced: inside the guest, where the workload can touch it, or on the host?
Where do snapshots and artifacts live, and can you point them at your own storage?
What does the audit trail show about what each session did?

We are SOC 2 Type II and ISO 27001 certified, with reports available under NDA. That answers the questionnaire. The architecture answers the harder question, which is what holds when the code misbehaves.

Frequently Asked Questions

Can agent-generated code run entirely inside our own data centre? Yes. CreateOS Sandbox supports full self-hosting of the control plane and storage, plus bring-your-own compute, so sessions execute on machines inside your perimeter with the same API you would use anywhere else.

Is outbound network access restricted by default? No. Outbound access is open until you set at least one egress rule. Once a rule exists, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest, so the workload cannot rewrite it. Inbound is closed by default.

Do we have to choose between our cloud and yours? No. The deployment modes are our cloud, your cloud (VPC), or your own machines, and the API is the same across them. You can also bring your own S3-compatible storage for snapshots and artifacts.

How do we start if we are a regulated company? Start with an architecture conversation rather than a trial. The Sandbox product page describes the deployment modes, and the docs cover the API and egress mechanics your security team will want to see.

Conclusion

"Cannot send agent-generated code to a shared cloud" is a constraint, not a dead end. The options scale with your constraint: bring your own compute when the machines must be yours, self-host the control plane and storage when nothing may leave the boundary, and bring your own storage when data location is the hard rule. In every case, insist on a per-session guest kernel and host-enforced egress, because those two controls are what a security review will probe. If that matches the conversation your team is having, talk to us about a deployment on your infrastructure.

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.