Sandbox With Outbound Network Allowlists Enforced Outside the VM

CreateOS Sandbox enforces each sandbox's outbound allowlist in the host kernel with eBPF, outside the VM boundary. Code inside the machine cannot rewrite the rules or route around them, even after a full guest compromise. Outbound stays open until you set a first rule; then everything not listed is denied. Inbound is closed by default.

Introduction

Start with the failure mode. If the code you run is untrusted, plan for the day it owns the machine. Any egress control inside that machine, whether an iptables rule, a proxy setting, or a wrapper script, becomes the attacker's tool the moment they get root. They read the allowlist, then they edit it. At that point the policy is a suggestion.

Containers blur the picture further. A container shares the host kernel with its runtime, so the boundary you are defending and the thing enforcing the defense sit in the same trust domain. That is a placement problem, not a hardening problem. CreateOS Sandbox moves enforcement outside the thing being defended: every workload runs in a Firecracker microVM with its own guest kernel, and egress rules are evaluated in the host kernel with eBPF before packets reach the network. For the attack side of this problem, see our piece on AI agent security and sandbox escapes.

Key Takeaways

Enforcement lives in the host kernel with eBPF, outside the VM, so a fully compromised guest cannot lift or loosen the allowlist.
Outbound is open until you set at least one rule. After that, everything else is denied. Inbound is closed by default regardless.
Four ways to set rules: the egress field at create time, a live API update with no restart, the SDK's setEgress method, or the CLI's firewall command.
Rules accept hosts, host:port pairs, wildcard subdomains, IPs, and CIDRs, with domain rules handled through a transparent proxy.
Egress is free, billing is per second, and new accounts start with 500 free credits.

Why CreateOS Sandbox Fits This Requirement

The requirement has two parts: a boundary the code cannot cross, and an enforcement point the code cannot reach. CreateOS Sandbox supplies both. The second part is the one most setups miss.

Each sandbox is a Firecracker microVM with its own guest kernel. Not a container, not a shared-kernel process namespace. Isolation is the machine's default state, not a setting someone has to remember to switch on.

On top of that boundary sits a per-sandbox egress allowlist enforced in the host kernel. Because the rules live on the far side of the VM boundary, a fully compromised guest, root and all, still cannot change them. The Sandbox product page documents the full surface, and the same API runs on your own machines when sessions have to stay inside your infrastructure.

Key Capabilities

The default state. A sandbox with no egress rules has open outbound access. Deny-by-default starts the moment you set the first rule. Inbound is closed by default no matter what your egress rules say. Design your provisioning around this: if the workload touches anything sensitive, the allowlist belongs in the create call, not in a follow-up ticket.

The rule shapes. Rules take a host, a host:port pair, a wildcard subdomain, an IP, or a CIDR range. Domain rules are handled through a transparent proxy, so the allowlist can name destinations the way your team already thinks about them.

The four ways to set them. Pass the egress field when you create the sandbox. Apply changes live with PUT /v1/sandboxes/{id}/egress, no restart needed. Call setEgress in the SDK (@nodeops-createos/sandbox on npm). Or run createos sandbox firewall set from the CLI. The docs carry the API and CLI reference for all four.

What it survives. The enforcement point sits in the host kernel, outside the guest. A full guest compromise does not reach it. That is the property the placement argument buys, and it is the difference between a policy and a suggestion.

What Is Proven Today

The claims above trace to shipped product, and the scale behind them is real.

2.6 million sandboxes created since June 2026.
CreateOS's own CI has run on sandboxes since July 2026, including its GitHub Actions runner and a coding-agent plugin.
Uptime runs 99%+ on infrastructure operated by NodeOps, the infrastructure company behind CreateOS, operating production infrastructure since December 2023.

Unit rates are published, not quoted on request. Per-second billing, $0 egress, and 500 free credits for new accounts sit on the Sandbox pricing page next to the shape limits, which run from a quarter CPU up to 8 CPUs with 16 GB of RAM.

We also say what is young. This is a young product, and the proof is the kind you can check: the isolation model, the egress enforcement, and our own daily use of both.

What to Weigh Before You Commit

The open default cuts both ways. Outbound is open until you set a rule. If your security review assumes deny-by-default outbound, set the allowlist at create time and write it into your runbook. The control is strong once set. Until then, the machine can reach the internet.

Egress is one axis. The allowlist governs what leaves the machine. It does not review what the code does with files or anything else inside its own boundary. Pair it with the isolation story, not instead of it.

No GPU sandboxes. If a workload needs GPU inference, that part runs somewhere else today.

Certifications are not the trust layer here. For the Sandbox surface, compliance certifications are on the roadmap, not shipped. The trust layer is the architecture: per-VM kernel isolation, host-enforced egress, and bring-your-own deployment if code cannot leave your boundary.

Frequently Asked Questions

Is outbound traffic blocked by default?

No. A sandbox with no egress rules has open outbound access. Deny-by-default starts once you set at least one rule, and from then on everything not on the list is denied. Inbound is closed by default regardless of your egress rules.

Can code inside the sandbox rewrite or bypass the allowlist?

No. The rules are enforced in the host kernel with eBPF, outside the VM. Code inside the sandbox cannot rewrite them or route around them, and the control holds through a full guest compromise.

How do I set or change the allowlist?

Four routes: the egress field at sandbox create time, PUT /v1/sandboxes/{id}/egress (applies live, no restart), the SDK's setEgress method, or the CLI's createos sandbox firewall set <sandbox> <host> command. Rules take hosts, host:port pairs, wildcard subdomains, IPs, and CIDRs. The docs carry the reference for each.

What does the egress control cost?

Nothing. Egress is $0, billing is per second, and new accounts start with 500 free credits. The Sandbox pricing page lists current rates and shape limits.

Conclusion

Spin up a sandbox, set a one-host allowlist, and hand the machine to code you do not trust. Watch the guest try to phone home somewhere else and fail. Then watch it try to edit the rule from inside and fail again. That second failure is the point: the enforcement is not where the attacker is.

Create a free account at createos.sh/products/sandbox and start with 500 credits. The quickstart runs untrusted code in about 10 lines.

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.