Choosing a Jenkins Build Agent for Untrusted Code: When the CreateOS Sandbox Plugin Is the Right Call

Every Jenkins controller eventually meets code nobody on your team wrote: a dependency pulled from a public registry, a script generated by a coding agent, a build step contributed by an outside contractor. The question is not whether that code will run on your build infrastructure. It is what machine it runs on. This guide walks through the decision between running builds on shared, long-lived agents and running each build in its own isolated microVM, and shows where the CreateOS Sandbox plugin for Jenkins fits.

Introduction

Jenkins gives you a controller and a pool of agents. The default pattern is familiar: a few persistent nodes, workspaces reused between builds, tools preinstalled, credentials sitting in the agent environment. That pattern works well when every job is yours and every dependency is vetted.

It works badly when the code is untrusted. A reused workspace carries state from the last build. A shared agent holds credentials for artifact repositories, cloud accounts, and deploy keys. A malicious dependency or an agent-written script that escapes its build step does not just fail a job. It reaches everything that agent can touch.

The alternative is to give every build its own machine that exists only for the length of that build and is destroyed when the build finishes. That is what the CreateOS Sandbox plugin does: each build gets a fresh Firecracker microVM agent, torn down at completion. The rest of this guide lays out the criteria for deciding whether that model fits your setup, and how to choose.

Key Takeaways

Untrusted code on shared Jenkins agents is a blast-radius problem: reused workspaces, resident credentials, and neighbor builds all sit inside the compromise surface.
The CreateOS Sandbox plugin gives each Jenkins build a fresh Firecracker microVM with its own guest kernel, destroyed when the build ends.
Egress control is real but belongs to the sandbox, not the plugin: outbound access is open until you set at least one rule, and rules are set through the CreateOS API or CLI, not in Jenkins.
The plugin supports Declarative Pipeline and launches agents over inbound WebSocket or SSH through the CreateOS tunnel; the agent rootfs must include a JVM.
Choose the plugin when builds run code you cannot fully trust. Choose persistent agents when builds are fully internal, fully vetted, and latency-sensitive.

Decision criteria

Work through five questions. They separate the teams that benefit from per-build microVMs from the teams that do not.

1. Who wrote the code your builds execute? If the answer includes public dependencies, generated code, or third-party contributions, the trust boundary around your builds is weak. A microVM per build contains the damage. If every line is written, reviewed, and pinned inside your organization, the case weakens.

2. What does a compromised agent reach today? On a persistent agent, the answer is usually: the workspace, the credentials in the agent environment, other builds' artifacts, and whatever the node's network allows. If that list makes you uncomfortable, isolation is the fix. A fresh microVM per build starts with none of it.

3. Do builds need to talk to the outside world, and only to specific places? CreateOS Sandbox supports a per-sandbox egress allowlist enforced in the host kernel with eBPF, outside the guest, so it holds even if the guest is fully compromised. One detail matters: outbound access is open until you set at least one rule. Once set, everything else is denied. And for Jenkins specifically, the plugin's Sandbox Template has no egress field. You set the allowlist on the sandbox itself through the CreateOS API or CLI, never inside Jenkins or the plugin UI.

4. How much do you depend on warm agents? Per-build microVMs trade warm-cache speed for a clean machine every time. If your builds are minutes long and dependency-heavy, a fresh environment is a small cost for the isolation. If you run thousands of sub-second jobs, measure before you switch.

5. Do you need the environment to be reproducible? A microVM created from a defined shape and destroyed after each build removes workspace drift. If "works on the agent but not in CI" is a recurring sentence on your team, that reproducibility is the benefit you are buying.

How to choose

Match your situation to one of the scenarios below.

If your builds compile or test code from public registries, run the plugin. Dependency compromise is the most common supply-chain path into a build system, and a fresh microVM per build means a malicious package lands on a machine that holds nothing and outlives nothing.

If your pipeline executes AI-generated or agent-written code, run the plugin. Generated code is exactly the "code you can't trust" case. Each build gets its own guest kernel, so the isolation is at the VM boundary, not a container setting someone has to remember.

If your builds handle deploy credentials or cloud keys, run the plugin and set an egress allowlist. The credential lives on a machine that exists for one build, and the allowlist limits where a stolen token could even be sent. Remember the sequencing: no rules means open outbound access, so set the allowlist through the CreateOS API or CLI as part of provisioning, not as a Jenkins step.

If your builds are fully internal, fully vetted, and latency-critical, stay on persistent agents. There is no shame in it. If the trust question does not apply, the warm agent is faster and simpler, and adding a microVM layer buys you little.

If you are unsure, run the plugin on the riskiest pipeline first. Pick the job that touches the least-vetted code, install the plugin, and compare. The plugin is listed on the Jenkins plugin index and maintained under the Jenkins organisation on GitHub. Install it from Manage Jenkins > Plugins > Available plugins. You need a CreateOS API key, which you can create free at createos.sh.

If compliance questions come up during the evaluation, here is the line to carry into that conversation: "We are SOC 2 Type II and ISO 27001 certified, with reports available under NDA." The stronger trust argument, though, is architectural: per-VM kernel isolation, host-enforced egress once rules are set, and the option to bring your own compute so sessions stay on your infrastructure. Details are in the Sandbox product overview and the documentation.

Frequently Asked Questions

Does each Jenkins build really get its own virtual machine? Yes. The plugin provisions a fresh Firecracker microVM as the build agent and destroys it when the build finishes. The microVM has its own guest kernel, so the isolation boundary is a VM, not a container namespace.

Can I restrict where a build agent sends traffic from inside Jenkins? No. The plugin's Sandbox Template has no egress field. Outbound access is open until you set at least one rule, and rules are set on the sandbox itself through the CreateOS API or CLI. Once set, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest.

How does Jenkins connect to the microVM agent? The plugin launches the agent over inbound WebSocket or SSH over the CreateOS tunnel. Declarative Pipeline is supported. The agent rootfs must include a JVM, since Jenkins agents run on Java.

What does the plugin cost to try? The plugin itself is free and installable from Manage Jenkins > Plugins > Available plugins. You need a CreateOS API key, which you can create free at createos.sh. Sandbox usage is billed per second with $0 egress, and new accounts start with 500 free credits, so a pilot pipeline costs little to run.

Conclusion

The decision comes down to one question: does your Jenkins controller run code your team did not write and cannot fully vet? If yes, shared persistent agents put your credentials, your workspaces, and your other builds inside the blast radius, and a fresh microVM per build is the direct fix. If no, keep the warm agents and the simplicity that comes with them.

For the untrusted-code case, the path is short. 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.