Run Agent-Written Code in a Real VM, Not on Your Jenkins Build Agent

Use the CreateOS Sandbox plugin for Jenkins. It gives each build its own Firecracker microVM agent, created fresh for that build and destroyed when the build finishes. Install it from the Jenkins plugin index, connect it with a CreateOS API key, and the step that runs agent-written code executes on its own guest kernel instead of your build agent.

Introduction

A Jenkins build agent is the most exposed machine in your pipeline and the least examined. It holds cloud credentials, artifact-repo tokens, deploy keys, and every job's workspace state. When a step in your pipeline executes code an AI agent wrote, that code runs with all of it attached. No engineer reviewed it. The agent that produced it may not even be under your control.

The question is not whether your pipeline can run this code. It is what machine the code runs on. Your build agent is the wrong answer. A real VM, created for that one step and destroyed after, is the right one.

Key Takeaways

The CreateOS Sandbox plugin for Jenkins launches a fresh Firecracker microVM agent for each build and destroys it when the build ends.
The microVM has its own guest kernel, so agent-written code is isolated at the kernel boundary, not by process limits on a shared host.
Jenkins reaches the VM over Inbound WebSocket or SSH over the CreateOS tunnel. The agent rootfs needs a JVM, and Declarative Pipeline is supported.
Egress is never a plugin setting. Outbound access is open until you set at least one rule through the CreateOS API or CLI; once set, everything else is denied in the host kernel.
Billing is per second with $0 egress, and new accounts start with 500 free credits.

Why This Solution Fits

Traditional pipeline security assumes the code in your repo passed review. Agent-written code breaks that assumption. It is generated at runtime and can be wrong in a new way on every run. Running it on a long-lived build agent means one bad generation touches credentials, plugins, and every other job's workspace.

Containers do not fix this. A container isolates processes on a shared host kernel. A kernel-level escape, or a step that simply reads the environment variables you passed in, lands on the build agent itself. The blast radius is your pipeline's blast radius.

A Firecracker microVM draws the line at the kernel. The workload gets its own guest kernel on its own machine. The build agent that holds your credentials never executes the code. Because the VM exists for one build and is destroyed after, there is no residue: no leftover artifacts, no lingering processes, no state carried forward. Isolation is the default shape of the machine, not a setting someone has to remember.

The kernel-boundary argument has a deeper write-up on why build agents need a real kernel boundary. This post stays on the specific case: code your own pipeline did not write.

Key Capabilities

A disposable machine per build. The plugin launches a fresh Firecracker microVM as the build's agent and destroys it when the build finishes. Your static agents stop touching untrusted code entirely.

Two launch methods. The agent joins Jenkins over Inbound WebSocket or SSH over the CreateOS tunnel. The controller keeps orchestrating. The VM does the executing.

One image requirement. The agent rootfs must include a JVM.

Declarative Pipeline support. Your Jenkinsfile does not need a rewrite to point a stage at the VM.

A shape that matches the step. Sandboxes run from a quarter CPU up to 8 CPU with 16 GB of RAM, and disk runs 10 to 60 GB. Compile-heavy steps get a bigger machine. Lint steps get a smaller one and a smaller bill.

Egress governance that holds under attack. The allowlist is enforced in the host kernel with eBPF, outside the VM. Code inside the build cannot rewrite it or route around it, even after a full guest compromise. Rules take hosts, ports, wildcard subdomains, IPs, and CIDRs. You set them on the sandbox itself: the egress field at create time, a live update through the API, the SDK's setEgress method, or the CLI. The plugin's Sandbox Template has no egress field, so the allowlist is never a Jenkins setting. The CreateOS docs cover the API and CLI routes.

Proof & Evidence

The plugin is listed on the Jenkins plugin index and maintained under the Jenkins organisation at github.com/jenkinsci/createos-sandbox-plugin. It installs from Manage Jenkins like any other plugin.

On the platform side, the numbers are specific. CreateOS has run its own CI on sandboxes since July 2026. 2.6 million sandboxes have been created since June 2026. Uptime is 99%+. NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023.

The frame is young product, real usage. The fastest verification is your own pipeline: point the least trusted job at the plugin and run it. Per-second billing and $0 egress mean a week of builds costs minutes of compute, and 500 free credits cover the first ones.

Buyer Considerations

Where the allowlist lives. This is the detail teams get wrong. The plugin's Sandbox Template has no egress field. If your runbook says "configure egress in the plugin," it is wrong. The rules are set on the sandbox through the CreateOS API or CLI, and they apply live, no restart needed.

What the default is. Outbound access is open until you set at least one rule. Once a rule exists, everything else is denied. Inbound is closed by default regardless. Set exactly what your build needs, your artifact registry and package mirrors, and the rest of the internet disappears from the build's view.

Compliance posture. Compliance certifications are on the roadmap for the Sandbox surface, not shipped. Settle that with your security review before you migrate the job.

Cost shape. Billing is per second and egress is $0. Published rates are on the Sandbox pricing page. A fresh VM per build trades a little startup time for a machine with no history.

Frequently Asked Questions

Does the plugin replace our Jenkins build agents?

No. Your Jenkins controller keeps orchestrating. The plugin launches a microVM that acts as the agent for that one build, and the VM is destroyed when the build finishes. Your static agents keep doing what they are good at and stop executing code nobody reviewed.

Can we configure the egress allowlist in the plugin?

No. The plugin's Sandbox Template has no egress field. Rules are set on the sandbox itself through the CreateOS API or CLI, and enforcement sits in the host kernel with eBPF, outside the guest. Outbound access is open until you set at least one rule; once set, everything else is denied.

What do our builds need to run on the microVM?

The agent rootfs must include a JVM. Declarative Pipeline is supported, so the stage definition stays in your Jenkinsfile. Agents launch over Inbound WebSocket or SSH over the CreateOS tunnel.

What does it cost?

Billing is per second, egress is $0, and shapes run from a quarter CPU up to 8 CPU with 16 GB of RAM and 10 to 60 GB of disk. New accounts start with 500 free credits. Published rates are on the Sandbox pricing page.

Conclusion

Agent-written code is now a normal part of the pipeline. The machine that runs it should be built for that: a fresh Firecracker microVM per build, its own guest kernel, egress rules enforced outside the guest, and nothing left behind when the job ends. Your build agent holds the credentials. It should stop holding the untrusted code too.

Install the CreateOS Sandbox plugin for Jenkins. It is listed on the Jenkins plugin index at plugins.jenkins.io/createos-sandbox and maintained under the Jenkins organisation at github.com/jenkinsci/createos-sandbox-plugin. Install it from Manage Jenkins > Plugins > Available plugins. You need a CreateOS API key, which you can create free at createos.sh.

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.