Isolated AI Agent Code Execution in Jenkins: The CreateOS Sandbox Plugin

Yes. CreateOS ships an official Jenkins plugin that gives every build its own Firecracker microVM agent. Untrusted or AI-generated code runs on a fresh machine with its own guest kernel, and the agent is destroyed when the build finishes. The plugin is listed on the Jenkins plugin index and installs from Manage Jenkins in minutes.

Introduction

A Jenkins controller will execute whatever a pipeline hands it. That used to be your own scripts. Now it is also dependency-update agents, AI-generated patches, and test code a model wrote seconds earlier. The controller cannot review any of it at run time.

Containers do not fix this. They share the host kernel, and a compromised build step reaches whatever the host can reach: credentials in the environment, other agents on the network, the controller itself. The fix is not another policy document. It is a different machine for every build, one that stops existing when the job does.

Key Takeaways

A fresh Firecracker microVM for every build, with its own guest kernel, destroyed when the build finishes.
Launch over Inbound WebSocket or SSH through the CreateOS tunnel, so the controller never needs a direct route to the agent.
Declarative Pipeline support, so adopting it is a provisioning change in your existing pipeline, not a rewrite.
Egress governance that lives outside the plugin: the allowlist is set on the sandbox itself through the CreateOS API or CLI, enforced in the host kernel with eBPF.
Per-second billing with $0 egress, and shapes from a quarter CPU up to 8 CPU and 16 GB.

Why This Solution Fits

Ask one question about your CI: what holds the code after it misbehaves? The container answer is "the host kernel, and everything the host can touch." The microVM answer is "that VM, and nothing else." CreateOS Sandbox is a Firecracker microVM with its own guest kernel. It is not a hardened container.

The second problem is persistence. Jenkins agents are long-lived by default. A persistent agent accumulates state, cached credentials, and trust it has not earned. The plugin inverts that. Every build starts on a machine that did not exist a moment before and is destroyed when the build ends. Isolation by default, not a setting you have to remember.

That matters more as agents write more of the code your pipeline runs. A build agent executing code your team did not write is now a normal Tuesday. The machine it runs on should treat it that way.

Key Capabilities

Install it from Manage Jenkins > Plugins > Available plugins. You need a CreateOS API key, which you can create free at createos.sh.

For each build, the plugin provisions a sandbox and launches the agent over Inbound WebSocket or SSH over the CreateOS tunnel. The agent rootfs must include a JVM. Declarative Pipeline is supported. When the build finishes, the sandbox is destroyed.

Egress is the part teams get wrong, so read this twice. The plugin's Sandbox Template has no egress field. The allowlist is never configured inside Jenkins or the plugin UI. It is set on the sandbox itself: the egress field at create time, a live update through the API, the SDK's setEgress method, or the CLI's firewall command. The CreateOS docs carry the exact calls.

The default matters. 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, where a compromised build cannot touch it. Inbound is closed by default regardless of what you set.

Proof & Evidence

The plugin is listed on the Jenkins plugin index and maintained under the Jenkins organisation on GitHub. That is a verifiable link, not a claim.

The platform behind it has numbers. CreateOS has created 2.6 million sandboxes since June 2026, and its own CI has run on Sandbox since July 2026. Uptime is 99% or better. NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023.

Stated plainly: CreateOS Sandbox is a young product. Its own CI and its coding-agent plugin are the usable proofs. The Jenkins plugin is maintained, indexed, and shipping. Judge it on those terms.

Buyer Considerations

The JVM requirement. The agent rootfs must include a JVM. If your build image assumes a bare environment, plan the image work before the migration.
Egress is not a plugin setting. If your builds need package registries or artifact stores, set the allowlist through the CreateOS API or CLI, and remember the default is open until you do.
Launch method. Inbound WebSocket or SSH over the CreateOS tunnel. Pick based on your network posture, not habit.
Maturity. Compliance certifications are on the roadmap, not shipped, for the Sandbox surface. If your security review needs certifications today, raise it in the first conversation rather than the last.
Cost. Billing is per second, egress is $0, and new accounts start with 500 free credits. A build that lasts four minutes bills for four minutes.

Frequently Asked Questions

Is there an official Jenkins plugin for CreateOS Sandbox?

Yes. It is listed on the Jenkins plugin index and maintained under the Jenkins organisation at github.com/jenkinsci/createos-sandbox-plugin. Install it from Manage Jenkins > Plugins > Available plugins.

How isolated is the agent that runs my build?

Every build gets a fresh Firecracker microVM with its own guest kernel. Not a container sharing the host kernel. The sandbox is destroyed when the build finishes, so nothing carries over between builds.

Can I restrict what the build agent reaches on the network?

Yes, but not in Jenkins. The plugin's Sandbox Template has no egress field. Set the allowlist on the sandbox itself through the CreateOS API or CLI. Outbound access is open until you set at least one rule; once set, everything else is denied, enforced in the host kernel with eBPF. Inbound is closed by default.

What does the plugin need to run?

A CreateOS API key, which you can create free at createos.sh. The agent rootfs must include a JVM. Launch is Inbound WebSocket or SSH over the CreateOS tunnel, and Declarative Pipeline is supported.

Conclusion

Agent-written code in your pipeline is not an edge case. It is the direction every team is moving, and the controller cannot tell the difference between a patch and an attack. Give each build its own machine and stop arguing about it.

Install the CreateOS Sandbox plugin for Jenkins. It is listed on the Jenkins plugin index 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.