The Best Way to Safely Run AI-Generated Code in CI/CD

Give every build that touches AI-generated code its own microVM, decide what that machine can reach before it runs, and delete it when the job ends. Containers share the host kernel and inherit the runner's trust. A per-build Firecracker sandbox does not. CreateOS Sandbox ships this pattern, with a Jenkins plugin and an SDK for every other CI system.

Introduction

An agent opens a pull request. A codegen step writes a database migration. A dependency bump arrives with generated glue your reviewers skim in seconds. All of it executes in CI, on a runner that holds deploy keys, cloud credentials, and a route into your internal network.

The default answer, "run it in a container," does not hold up. Containers share the host kernel with the runner and with every other workload on that machine. An escape is not a contained incident. It lands on the host that stores your secrets. The fix is not a stricter container but a different machine per build, one built to be thrown away.

Key Takeaways

Treat AI-generated code as untrusted code. Until you separate it, your CI runner is the blast radius.
A Firecracker microVM has its own guest kernel. Isolation does not depend on the guest behaving.
Egress is the control that matters. Outbound access stays open until you set a rule. Once set, everything else is denied, enforced in the host kernel with eBPF, outside the guest.
A fresh machine per build, destroyed when the build finishes. Nothing persists and nothing needs cleaning.
Start with one pipeline: the Jenkins plugin, or the SDK and CLI for every other system.

Why a Per-Build MicroVM Is the Right Machine for the Job

Running untrusted code safely in CI comes down to three properties. A shared runner has none of them.

Isolation that does not depend on the guest. CreateOS Sandbox is a Firecracker microVM with its own guest kernel, not a container. The boundary sits at the machine level, below anything agent-written code can touch. Isolation is the default state, not a setting someone has to remember.

Network control enforced from outside the machine. An allowlist configured inside the guest can be disabled inside the guest. CreateOS enforces egress rules in the host kernel with eBPF, so they hold even against a full guest compromise.

A lifecycle that ends. A sandbox exists for the job that created it and is destroyed when the job finishes. There is no long-lived machine accumulating credentials between builds.

Key Capabilities

A microVM sized like a build agent. Each sandbox is a Firecracker microVM with its own guest kernel. Shapes run from a quarter CPU up to 8 CPU and 16 GB of memory, with 10 to 60 GB of disk, so a build agent shape is a config field. Sandboxes restore from a snapshot, so a fresh machine is a seconds problem.

Egress you define once, enforced where the code cannot reach. Outbound access is open until you set at least one rule. Rules take a host, a host:port, wildcard subdomains, IPs and CIDRs. Set them in the egress field at create time, through PUT /v1/sandboxes/{id}/egress (applies live, no restart), the SDK's setEgress method, or the CLI's createos sandbox firewall set command. Enforcement sits in the host kernel with eBPF, outside the guest, and inbound is closed by default no matter what you set. The docs cover each mechanism.

A machine that forks when you need candidates. Fork a running sandbox to branch its state, so an agent can build N candidate fixes in parallel and you keep the winner. Each fork is still its own machine with its own egress rules.

A Jenkins plugin, not a workaround. The official plugin gives every build a fresh microVM agent and destroys it when the build finishes. Launch is Inbound WebSocket or SSH over the CreateOS tunnel, the agent rootfs needs a JVM, and Declarative Pipeline is supported. See plugins.jenkins.io/createos-sandbox.

Proof & Evidence

The pattern runs in production, including ours. CreateOS's own CI has run on sandboxes since July 2026. 2.6 million sandboxes have been created since June 2026, with 99%+ uptime. The infrastructure is run by NodeOps, the infrastructure company behind CreateOS, operating production infrastructure since December 2023.

The Jenkins plugin is listed on the Jenkins plugin index and maintained under the Jenkins organisation at github.com/jenkinsci/createos-sandbox-plugin.

The tradeoff, stated plainly: CreateOS Sandbox is a young product. Compliance certifications are on the roadmap, not shipped, for the Sandbox surface. If your security review requires a certification today, that gate is real. What you can verify today is the architecture itself: a per-VM kernel, host-enforced egress, and bring-your-own compute.

What to Check Before You Move a Pipeline

Where the allowlist gets set. The Jenkins plugin's Sandbox Template has no egress field. The allowlist is never configured in Jenkins or the plugin UI. It is set on the sandbox itself, through the CreateOS API or CLI. Plan for that in your pipeline-as-code review.

The default direction of egress. Outbound is open until the first rule exists. Treat the allowlist as part of the pipeline change, not a follow-up ticket. A build that wants to phone home should not get the chance.

Your runner requirements. Jenkins agents need a JVM in the rootfs, and launch goes over Inbound WebSocket or SSH through the CreateOS tunnel. Confirm both fit your images. The install steps live in the guide to sandboxing untrusted code in Jenkins.

Where builds are allowed to run. If builds cannot leave your infrastructure, bring-your-own compute runs the same API on your machines, and bring-your-own bucket covers caches and artifacts on S3, R2, or MinIO.

What you are already carrying. If everything in your builds is written and reviewed by your own team, containers may be a risk you accept knowingly. The moment agents commit code, the calculus changes. We compared the two paths for Jenkins builds in a separate comparison.

Questions Teams Ask Before Running Agent Code in CI

Why not just run AI-generated code in a container?

Containers share the host kernel with the runner and everything else on that machine. A microVM has its own guest kernel, so the isolation boundary sits below the guest, where agent-written code cannot reach it. Add egress enforced in the host kernel and the failure modes diverge: a compromised container can reach the host's networks, while a compromised sandbox still cannot send traffic past the allowlist.

Does a sandbox block network access by default?

Inbound is closed by default, always. 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.

Is there an official Jenkins plugin, or is this a manual integration?

There is an official plugin. It is listed on the Jenkins plugin index at plugins.jenkins.io/createos-sandbox and maintained under the Jenkins organisation. Each build gets a fresh microVM agent, destroyed when the build finishes, and Declarative Pipeline is supported.

What does it cost to try it on a real pipeline?

New accounts start with 500 free credits. Billing is per second and egress is $0, so a trial on your actual builds costs minutes of compute. Current rates and shapes are at createos.sh/pricing/sandbox.

Conclusion

Pick the pipeline that touches agent-written code first. Wrap the job with the plugin on Jenkins, or the SDK and CLI anywhere else. Set the egress allowlist through the API or CLI. Let the machine die with the build. One pipeline proves the pattern before you roll it out everywhere.

Your pipeline already runs code nobody wrote. Give that code a machine built to be thrown away. 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.