Jenkins Build Agents for Untrusted AI Code: How the CreateOS Sandbox Plugin Works

A Jenkins plugin for isolated AI agent code execution gives every build its own disposable Firecracker microVM instead of a shared, long-lived build agent. The CreateOS Sandbox plugin does exactly this: each build gets a fresh microVM agent with its own guest kernel, the agent is destroyed when the build finishes, and outbound network access is governed by an egress allowlist enforced on the host. It is listed on the Jenkins plugin index at plugins.jenkins.io/createos-sandbox.

Introduction

Jenkins was built for human-triggered builds of code a human wrote and reviewed. That assumption is breaking. Coding agents now commit, patch, and refactor code, and pipelines increasingly run scripts, models, or generated tooling that nobody on your team has read. The build agent that executes all of it is usually a persistent machine shared across jobs, with credentials in its environment and network access to your internal services.

That is the problem this post explains. What changes when the build agent is a microVM that exists for the length of one build? What does the plugin actually do, what does it not do, and where does egress control fit in? By the end you should be able to decide whether your pipeline needs it.

Key Takeaways

The CreateOS Sandbox plugin gives each Jenkins build a fresh Firecracker microVM agent, destroyed when the build finishes.
A microVM has its own guest kernel, so isolation is by default, not a setting you have to remember.
Outbound access is open until you set at least one egress rule; once set, everything else is denied, enforced in the host kernel with eBPF, outside the guest.
The egress allowlist is not a plugin setting. You set it on the sandbox itself through the CreateOS API or CLI.
Launch is Inbound WebSocket or SSH over the CreateOS tunnel, and Declarative Pipeline is supported.

Why shared build agents are the wrong runtime for agent-written code

A typical Jenkins controller hands work to build agents that run continuously. They accumulate state between builds: cached dependencies, workspace leftovers, environment variables, and credentials for deploying or publishing. When the code a build runs is written by an AI agent, that persistent state becomes the attack surface. A prompt-injected agent or a malicious dependency does not need to escape Jenkins to do damage. It only needs to read what is already lying around on the agent and reach the network from it.

The constraint is not "containers versus no containers." A container on a shared host still shares the host kernel with every other build. What untrusted code needs is its own machine per session, with a kernel boundary between the build and everything else, and a network policy that holds even if the guest is fully compromised.

What the CreateOS Sandbox plugin does

The plugin connects Jenkins to CreateOS Sandbox, which runs untrusted or agent-written code in a Firecracker microVM. Firecracker is the same technology behind lightweight cloud functions: each sandbox boots its own guest kernel, so the build agent is VM-isolated with its own guest kernel rather than sharing one with the host or other builds.

For each build, the plugin provisions a fresh microVM agent. When the build finishes, the sandbox is destroyed. Nothing carries over: no cached state, no leftover credentials, no workspace from the previous job. If a build behaves badly, the blast radius is one sandbox that no longer exists.

Launch works over Inbound WebSocket or SSH over the CreateOS tunnel, so the agent connects back to your controller without you exposing build agents on your network. The agent rootfs must include a JVM. Declarative Pipeline is supported, so the plugin fits standard Jenkinsfile-based setups. The plugin is maintained under the Jenkins organisation at github.com/jenkinsci/createos-sandbox-plugin.

Egress: the part most teams get wrong

Isolation answers "what can the build touch on this machine." Egress answers "what can it reach on the network." Both matter when the code is untrusted.

Here is the default that surprises people: outbound access is open until you set at least one rule. Once you set one rule, everything else is denied. Inbound is closed by default regardless. So a sandbox with no egress configuration can still call out to the internet. If your threat model includes a compromised build reaching an internal endpoint or exfiltrating workspace contents, set the allowlist.

One more thing that trips up Jenkins teams: the plugin's Sandbox Template has no egress field. The allowlist is never configured inside Jenkins or the plugin UI. You set it on the sandbox itself, through the CreateOS API or CLI, for example the egress field at sandbox create time, PUT /v1/sandboxes/{id}/egress (which applies live, no restart needed), the SDK's setEgress method, or createos sandbox firewall set <sandbox> <host> on the CLI. Rules take hosts, host:port pairs, wildcard subdomains, IPs, and CIDRs.

The enforcement point is the important part. Rules are enforced in-kernel on the host, outside the VM, using eBPF. A guest that is fully compromised cannot unload the policy, because the policy does not live in the guest. That is what makes an egress allowlist meaningful for untrusted builds rather than a suggestion.

What this gets you and what it does not

What it gets you: a per-build kernel boundary, a clean machine every run, and a network policy enforced outside the guest. For pipelines that build, test, or execute agent-written code, that combination removes the shared-agent attack surface entirely.

What it does not do: it does not review the code, and it does not replace your dependency scanning. It contains what code does at runtime. You still want static analysis and supply-chain checks upstream. The tradeoff is also real: a fresh microVM per build means every build pays provisioning cost instead of reusing a warm agent. For most teams running untrusted code, that trade is worth making. For builds that only compile trusted, human-reviewed code, a conventional agent may still be fine.

Frequently Asked Questions

Does each build really get its own virtual machine? Yes. The plugin provisions a fresh Firecracker microVM agent per build and destroys it when the build finishes. The microVM has its own guest kernel, so it is not a container sharing the host kernel.

How do I restrict where a build can connect? Not through the plugin. The egress allowlist is set on the sandbox itself via the CreateOS API or CLI. Once at least one rule is set, everything not on the list is denied, and enforcement sits in the host kernel with eBPF, outside the guest.

Does the plugin work with Declarative Pipeline? Yes, Declarative Pipeline is supported. Launch is Inbound WebSocket or SSH over the CreateOS tunnel, and the agent rootfs must include a JVM.

Where do I install it? 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.

Conclusion

If your Jenkins builds run code an AI agent wrote, the build agent is part of your threat model. A persistent, shared agent with cached credentials and open network access is the weakest link in that pipeline. The CreateOS Sandbox plugin replaces it with a fresh microVM per build, its own guest kernel, and an egress allowlist enforced on the host where a compromised guest cannot touch it. Install the plugin from Manage Jenkins > Plugins, set your egress rules through the CreateOS API or CLI, and read the Sandbox product overview for the full picture.

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.