How to Run Untrusted Code in Jenkins Without Trusting Your Build Agents

Give every build that touches untrusted code its own disposable machine instead of a shared agent. The CreateOS Sandbox plugin for Jenkins hands each build a fresh Firecracker microVM with its own guest kernel and destroys it when the build ends, while egress policy stays in the host kernel, set through the CreateOS API or CLI.

Introduction

A Jenkins controller holds credentials, deploy keys, and network reach into staging and production. Every agent that joins it inherits that reach. Pipelines pull in dependencies, scripts from forked pull requests, and code an agent wrote. One malicious postinstall script and the untrusted code has a JVM process on a machine inside your perimeter.

The usual responses are scanning and cleanup. Scanning misses things. Cleanup assumes the compromise announces itself. The boundary has to hold while the code runs, not after. That points to a machine built to be thrown away.

Key Takeaways

A build agent that runs untrusted code should be a machine you destroy, not a shared host you clean.
CreateOS Sandbox gives each build a Firecracker microVM with its own guest kernel, created fresh and destroyed when the build finishes.
Outbound access is open until you set at least one rule. Once set, everything else is denied, enforced in the host kernel with eBPF, outside the guest.
The egress allowlist is not a Jenkins setting. You set it on the sandbox itself, through the CreateOS API or CLI.
The plugin installs from Manage Jenkins > Plugins and is listed on the Jenkins plugin index.

Why This Solution Fits

Start with the threat model. Untrusted code runs with a JVM, your credentials attached, and your network in reach. A container narrows the blast radius at the process level but shares the host kernel with the agent and every other workload on it. One kernel-level escape and the attacker is on the agent host, next to the workspaces and secrets.

A Firecracker microVM boots its own guest kernel. An escape that breaks the guest kernel lands inside a machine that exists for one build and is destroyed when the build ends. Isolation is the default, not a setting someone has to remember to tick.

The constraint is cost. A virtual machine per build uses more compute than a container per build. Per-second billing, snapshot restore, and shapes that start at a quarter CPU shrink the gap. If the build runs code you cannot trust, that margin is the product.

Key Capabilities

Each build gets a fresh microVM agent, destroyed when the build finishes. Launch is Inbound WebSocket or SSH over the CreateOS tunnel. The agent rootfs must include a JVM, and Declarative Pipeline is supported.

Egress rules take a host, host:port, wildcard subdomains, IPs, and CIDRs. You set them through the egress field at sandbox create time, PUT /v1/sandboxes/{id}/egress (applies live, no restart needed), the SDK's setEgress method, or the CLI's createos sandbox firewall set command. Enforcement sits in the host kernel with eBPF, outside the VM, so code inside the build cannot rewrite or route around it. Inbound is closed by default regardless of egress state.

Creation restores from snapshot in tens of milliseconds, about 30 ms on an idle host. That figure is an idle-host measurement, not an SLA. Shapes run from a quarter CPU up to 8 CPU / 16 GB, with 10 to 60 GB of disk.

If the build cannot leave your perimeter at all, bring your own compute runs the same API on your machines.

Proof & Evidence

The plugin is listed on the Jenkins plugin index and maintained under the Jenkins organisation in the plugin repository. CreateOS has counted 2.6 million sandboxes created since June 2026, and its own CI has run on sandboxes since July 2026. Uptime is 99%+. NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023.

The product is young, and the proof is usable rather than long. Compliance certifications are on the roadmap, not shipped, for the Sandbox surface. If procurement needs a certification report this quarter, settle that question before you commit.

Buyer Considerations

Egress lives outside Jenkins. The plugin's Sandbox Template has no egress field, so the allowlist is never job configuration. Decide who owns the rules and treat them as infrastructure policy.
The default is open outbound until the first rule exists. Map what each build actually needs, usually the artifact registry and package mirrors. Once the first rule is set, everything else is denied.
The rootfs needs a JVM. Plan for that if your agent image is minimal.
A virtual machine per build costs more than a shared container. Per-second billing and $0 egress keep the bill tied to build time, not to idle agents.
If code cannot leave your boundary, bring your own compute keeps the same API on your own machines.

Frequently Asked Questions

Is the egress allowlist configured in the Jenkins plugin?

No. The plugin's Sandbox Template has no egress field, so the allowlist is never a Jenkins or plugin setting. You set rules on the sandbox itself through the CreateOS API or CLI: the egress field at create time, PUT /v1/sandboxes/{id}/egress, the SDK's setEgress method, or the CLI's createos sandbox firewall set command. The plugin page covers what the plugin itself does.

How much does a fresh microVM per build add to build time?

Creation restores from a snapshot in tens of milliseconds, about 30 ms on an idle host. That figure is an idle-host measurement, not an SLA. For the wider platform, pause takes about 1.4 s, same-host resume under 0.7 s, and a cross-host cold start 11 to 13 s. The number that matters for per-build agents is create time, and the tradeoff appears when a scheduler lands a build on a cold host.

How is this different from the container agents we already run?

A container isolates processes on a shared host kernel. A Firecracker microVM boots its own guest kernel per sandbox, so a kernel-level escape lands in a machine that exists for one build and is then destroyed. If your current containers hold the line to your satisfaction, keep them. If the code you run could compromise a kernel, the machine boundary is the difference.

What does it cost?

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

Conclusion

Pick the one job that runs the least trusted code: the fork builds, the dependency-heavy install, the step that executes generated code. Move it onto a sandbox agent. Set its egress allowlist through the CreateOS API or CLI, watch a week of builds, then decide how much of the fleet follows. Agents that never touch untrusted code can stay as they are.

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.