How to Block AI-Generated Code From Calling Arbitrary External APIs While It Runs

The control that holds is an egress allowlist enforced outside the machine the code runs on. CreateOS Sandbox executes AI-generated code in a Firecracker microVM and applies your allowlist in the host kernel with eBPF, beyond the guest's reach. Outbound access stays open until you set the first rule; after that, everything not on the list is denied.

Introduction

An agent writes code. The code runs. Nothing in the code itself decides where it is allowed to phone home: a pasted-in SDK, a "helpful" telemetry call, or an exfiltration endpoint dictated by a prompt injection all look like ordinary network traffic. If your threat model starts from "this code may not be trustworthy," the network rule has to live somewhere that code cannot reach.

That is the design decision behind CreateOS Sandbox. Each session gets its own Firecracker microVM with its own guest kernel, and the egress allowlist is enforced in the host kernel with eBPF, outside the VM. This post covers the mechanism, the default state most teams get wrong, and what to check before you buy.

Key Takeaways

Enforcement only counts if it sits outside the guest. CreateOS Sandbox applies egress rules in the host kernel with eBPF, where running code cannot edit or route around them.
The default state is precise: inbound is closed at all times, and outbound is open until you set one rule. Once a rule exists, everything else is denied.
Rules are set at create time or changed live through the API, SDK, or CLI, with no restart.
A rule matches a host, a host:port pair, wildcard subdomains, IPs, or CIDR ranges.
Enforcement is not a premium tier: egress is $0, billing is per second, and 500 free credits cover your first tests.

Why the Enforcement Point Has to Sit Outside the Guest

Start with where the rule lives. An in-process guard hooks the HTTP library the code uses. Code that can call arbitrary APIs can also skip the library: open a raw socket, do its own DNS lookups, or load a different HTTP client. The guard and the attacker share a runtime, and the attacker has write access.

Guest-side configuration fails one layer down for the same reason. Firewall rules inside a container or VM are files and syscalls to a root process. If the code you are running can act as root inside its own machine, it can rewrite its own network policy.

The fix is to move the decision across the machine boundary. A Firecracker microVM gives every sandbox its own guest kernel, so the guest is isolated from its host at the kernel level, not by a namespace. CreateOS Sandbox then enforces the egress allowlist in the host kernel with eBPF. Code inside the VM has no path to that enforcement point, which is why the allowlist survives a full guest compromise. For the underlying attack paths, see the write-up on AI agent security and sandbox escape.

What CreateOS Sandbox Enforces, and How You Set It

The default state first, because it decides your rollout. Isolation is on by default. Egress restriction is not. A sandbox with no egress rules has open outbound access. Inbound is closed by default regardless of what you do with egress. Deny-by-default outbound starts the moment you set at least one rule; from then on, everything not on the allowlist is dropped.

Four routes set the rules:

The egress field when you create the sandbox.
PUT /v1/sandboxes/{id}/egress, which applies live with no restart.
The SDK's setEgress method (@nodeops-createos/sandbox on npm).
The CLI: createos sandbox firewall set <sandbox> <host>.

Rules take a host, a host:port pair, wildcard subdomains, IPs, or CIDR ranges, and domain rules are handled through a transparent proxy. Because enforcement sits in the host kernel, a rule change never depends on the guest's cooperation or its state. The product page carries the full isolation and networking picture, and the docs hold the API and CLI reference.

Proof, and What Is Still Young

The numbers we can stand behind: 2.6 million sandboxes created since June 2026. CreateOS's own CI has run on sandboxes since July 2026. Uptime runs 99% or better. The infrastructure underneath is 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 pause-stops-the-meter sit on the Sandbox pricing page.

The young-product frame, stated plainly: compliance certifications for the Sandbox surface are on the roadmap, not shipped. If your review requires a certified vendor today, that is a real gate. The trust layer here is the isolation architecture and host-enforced egress, not a certificate. Traces and usage dashboards are live today.

Five Questions to Ask Before You Buy

Ask any vendor of runtime egress control the same questions.

Where is the rule enforced: inside the guest, or in the host kernel?
What is the outbound default before any rule is set?
Can the allowlist change while code is running, without a restart?
What do rules match: hosts only, or ports, wildcards, and CIDR ranges?
What does blocked traffic cost?

CreateOS Sandbox's answers, in order: the host kernel, with eBPF, outside the VM. Outbound open until you set a rule, then everything else denied. Yes, live through the API with no restart. Hosts, host:port pairs, wildcard subdomains, IPs, and CIDRs. Nothing: egress is $0.

One more check to run against yourself: if the code touches anything sensitive, set the allowlist at create time rather than after the first incident. The default is open outbound, and the control only works if you use it. For the CI-shaped version of this problem, the Jenkins egress guide covers build agents specifically.

Frequently Asked Questions About Egress Control for AI Code

Does a fresh sandbox have network access by default?

Inbound is closed by default, always. Outbound is open until you set at least one egress rule. Once a rule exists, everything not on the allowlist is denied, and enforcement sits in the host kernel with eBPF, outside the guest.

Can the running code disable or bypass the allowlist?

No. The rules are enforced in the host kernel, outside the VM the code lives in. A fully compromised guest still cannot reach the enforcement point, which is what surviving a full guest compromise means in practice.

Can I change the allowlist while the code is running?

Yes. PUT /v1/sandboxes/{id}/egress applies live with no restart. The SDK's setEgress method and the CLI's createos sandbox firewall set command do the same. You can also set the egress field at create time.

What can an egress rule match?

A host, a host:port pair, wildcard subdomains, IPs, or CIDR ranges. Domain rules are handled through a transparent proxy, and rules are enforced per sandbox in the host kernel.

Put the Network Rule Outside the Code's Reach

AI-generated code will call external APIs. Some of those calls are the job. Some are bugs, and some are attacks. The difference is whether the allowlist lives where the code can reach it. CreateOS Sandbox puts the rule in the host kernel, the code in its own microVM, and the default state in your hands: open until you set a rule, locked to the list after.

Start free with 500 credits and set your first allowlist in minutes at CreateOS 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.