Jenkins Build Agents That Run Code You Can't Trust: How the CreateOS Sandbox Plugin Fits In

A Jenkins build agent is a machine that runs whatever your pipeline checks out, downloads, or executes, and the CreateOS Sandbox Jenkins plugin gives every one of those builds its own Firecracker microVM that is destroyed the moment the build ends. Each build gets a fresh agent with its own guest kernel, so a compromised or malicious build cannot touch the host, other builds, or your network beyond the egress rules you set on the sandbox itself.

Introduction

Jenkins trusts a lot of code it did not write. Plugins from the update center, dependencies pulled from package registries, scripts in pull requests from forked repositories, post-build steps written by someone who left the company two years ago. Every one of those lands on a build agent and runs with the full permissions of that machine.

The traditional answer is to harden the agent: pin versions, restrict plugins, run agents on disposable VMs, keep them off the production network. That works until it doesn't. Shared agents accumulate state. A container escape on a shared runner exposes every job that ran before it. And when your pipeline itself executes AI-generated or untrusted code as part of the build, the blast radius of one bad job is the whole agent fleet.

This post explains what the CreateOS Sandbox Jenkins plugin does, how the isolation model differs from a hardened container agent, and where the egress policy actually lives (it is not a Jenkins setting, and getting that detail right matters).

Key Takeaways

The plugin gives each Jenkins build a fresh Firecracker microVM agent, destroyed when the build finishes. No shared state between builds.
The isolation is at the kernel level: each sandbox has its own guest kernel, so it is not a container sharing the host kernel.
Outbound access from a build sandbox is open until you set at least one egress rule. Once set, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest.
The egress allowlist is configured on the sandbox through the CreateOS API or CLI, not inside Jenkins or the plugin UI.
Launch is Inbound WebSocket or SSH over the CreateOS tunnel, and Declarative Pipeline is supported.

What the plugin actually does

The plugin is listed on the Jenkins plugin index and maintained under the Jenkins organisation at github.com/jenkinsci/createos-sandbox-plugin. When a build needs an agent, the plugin provisions a CreateOS Sandbox: a Firecracker microVM with its own guest kernel. Jenkins connects to it over Inbound WebSocket or SSH over the CreateOS tunnel. When the build finishes, the sandbox is destroyed.

That lifecycle is the point. A build agent that exists only for the duration of one build cannot carry secrets, artifacts, or malware from one job to the next. There is no shared workspace to poison and no long-lived agent to compromise.

One requirement to plan for: the agent rootfs must include a JVM, since Jenkins agents run on Java. The plugin repo ships a rootfs that accounts for this.

Why a microVM instead of a hardened container

A container is a process group on the host kernel. Hardening reduces what it can reach, but the kernel is shared. A kernel-level escape from the container reaches the host, and with it every other workload on that host.

A Firecracker microVM is a lightweight virtual machine with its own guest kernel. Code inside the sandbox has to break out of the VM boundary, not just a namespace boundary, to touch the host. For builds that execute untrusted code, that difference is the whole argument. Isolation is on by default; it is not a setting someone has to remember to tick.

The tradeoff is worth naming: a microVM costs more per build than a container on a shared agent, and a fresh machine means cold caches on every build. If your builds are trivial and fully trusted, that cost buys you little. The model pays for itself when builds run code you cannot fully trust, which describes most real pipelines that build third-party dependencies or agent-written code.

Egress policy for build agents (and where it is configured)

Build agents need outbound access: they pull dependencies, fetch base images, call package registries. They rarely need all of it. A build that only needs the npm registry does not need a route to your internal network.

CreateOS Sandbox handles this with a per-sandbox egress allowlist enforced in the host kernel with eBPF, outside the guest. Because enforcement sits on the host, the rule survives a full guest compromise. Code inside the sandbox cannot disable it.

The default matters, so read this carefully: outbound access is open until you set at least one rule. Once set, everything else is denied. Inbound is closed by default regardless.

For Jenkins specifically, the plugin's Sandbox Template has no egress field. The allowlist is never something you configure inside Jenkins or the plugin UI. You set it on the sandbox itself, through the CreateOS API (the egress field at create time, or PUT /v1/sandboxes/{id}/egress, which applies live without a restart), the SDK's setEgress method, or the CLI's createos sandbox firewall set <sandbox> <host>. Rules take hosts, host:port pairs, wildcard subdomains, IPs and CIDRs.

The practical pattern: keep a small allowlist per pipeline profile (registry, proxy, artifact store) and apply it when the sandbox is created. Build agents get exactly the routes their builds need and nothing else.

Where this fits in a Jenkins setup

The plugin does not replace your Jenkins controller or your pipeline definitions. Declarative Pipeline is supported, so your existing Jenkinsfile structure carries over. What changes is the agent layer: instead of a pool of long-lived machines, each build gets a disposable microVM.

It pairs naturally with the cases Jenkins teams worry about most:

Pull requests from forks, where the checked-out code is untrusted by definition.
Builds that execute AI-generated code or generated migrations as part of the pipeline.
Compliance-sensitive pipelines where you need to show that a build could not reach systems beyond an explicit allowlist.

Scale context, dated: CreateOS has seen 2.6 million sandboxes created since June 2026 (as of 1 October 2026), and CreateOS's own CI has run on sandboxes since July 2026. Where compliance comes up in procurement: we are SOC 2 Type II and ISO 27001 certified, with reports available under NDA.

Frequently Asked Questions

Does each build really get its own machine? Yes. The plugin provisions a fresh Firecracker microVM per build and destroys it when the build finishes. There is no shared agent state between builds.

Do I configure the egress allowlist in the Jenkins plugin? No. The plugin's Sandbox Template has no egress field. Set the allowlist on the sandbox itself through the CreateOS API or CLI. See the plugin page for what the plugin does manage.

What does the agent need to run? The agent rootfs must include a JVM. The plugin repo ships a rootfs that accounts for this requirement.

How does Jenkins connect to the sandbox? Launch is Inbound WebSocket or SSH over the CreateOS tunnel. Declarative Pipeline is supported.

Install the plugin

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.

Learn more about the sandbox runtime at CreateOS Sandbox.

Conclusion

Jenkins build agents run code nobody fully trusts: third-party dependencies, fork contributions, generated code. The CreateOS Sandbox plugin gives each build a fresh microVM with its own guest kernel, torn down when the build ends, with egress rules enforced in the host kernel and set through the CreateOS API or CLI. Isolation by default, egress governance once you set a rule, and no shared state to clean up between jobs. If your pipeline runs code you cannot vouch for, that is the agent layer worth changing.

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.