Egress Policy for Jenkins Build Agents: Why the Allowlist Belongs Outside the Build

A Jenkins build agent that runs untrusted code needs two things at once: a fresh machine for every build, and an outbound network policy that the code inside the build cannot change. The CreateOS Sandbox plugin for Jenkins gives each build its own Firecracker microVM, and the egress allowlist that governs what that build can reach is enforced in the host kernel, outside the guest. That placement is the whole point.

Introduction

Jenkins agents are, by design, machines that run whatever the pipeline tells them to run. Check out the repo, run the tests, execute the build scripts. When a dependency is compromised, a build step is malicious, or a maintainer account is hijacked, the build agent is the machine that executes the attack. Most teams accept this because rebuilding the CI topology around it is expensive.

There is a cheaper fix. Give every build its own microVM that is destroyed when the build finishes, and put the outbound network policy in the host kernel where a compromised guest cannot touch it. That is what CreateOS Sandbox does, and the CreateOS Sandbox plugin for Jenkins brings it into your pipeline. This post explains how the pieces fit, what the egress default actually is, and where the allowlist is configured (it is not a plugin setting).

Key Takeaways

Each Jenkins build gets a fresh Firecracker microVM agent, destroyed when the build finishes. No state carries over between builds.
Outbound access from a sandbox is open until you set at least one egress rule. Once set, everything else is denied.
The allowlist is enforced in the host kernel with eBPF, outside the guest, so it survives a full guest compromise.
For Jenkins specifically, the allowlist is not configured in the plugin or in Jenkins. It is set on the sandbox through the CreateOS API or CLI.
The plugin is listed on the Jenkins plugin index and maintained under the Jenkins organisation.

Why build agents are the soft spot in CI security

A build agent holds credentials by necessity. It needs access to your artifact repository, your package registries, your cloud accounts for deployment steps. It also runs code you did not fully audit: every transitive dependency in every requirements.txt, package.json, and pom.xml in your organisation.

The standard mitigation is a shared agent with some hardening. That has two failure modes. First, state leaks between builds on the same host: caches, workspace leftovers, installed packages. Second, the network boundary is the same for every build, so one compromised step can reach whatever the agent as a whole can reach.

The alternative is to make the unit of isolation the build itself. Each build gets its own machine with its own guest kernel, and the machine stops existing when the build ends. That is the model the plugin implements.

What the plugin actually does

The CreateOS Sandbox plugin provisions a fresh microVM agent for each build and destroys it when the build finishes. Launch is Inbound WebSocket or SSH over the CreateOS tunnel. Declarative Pipeline is supported. The agent rootfs must include a JVM, and the plugin repo ships a rootfs with that requirement in mind.

Underneath, each agent is a Firecracker microVM with its own guest kernel. It is not a container on a shared host. The kernel boundary is what makes the egress story in the next section enforceable: the policy lives on the host side of that boundary.

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

The egress default, stated precisely

This is the part teams get wrong, so it is worth being exact.

A sandbox with no egress rules set has open outbound access. Isolation is on by default; egress restriction is not. Deny-by-default starts once you set at least one rule. From that point, everything not on the allowlist is denied.

Inbound is closed by default regardless of egress rule state. That half is always true.

So the correct mental model is: open by default, deny-by-default once you set a rule, and the rule set is enforced in the host kernel with eBPF, outside the VM. A build that is fully compromised inside its microVM cannot edit, disable, or tunnel around a policy it cannot see the enforcement point of. The allowlist survives a full guest compromise because the guest is not the enforcer.

Where the allowlist is configured for Jenkins builds

Here is the detail that matters for Jenkins users: the plugin's Sandbox Template has no egress field. You do not configure the allowlist inside Jenkins, and you do not configure it in the plugin UI.

The allowlist is set on the sandbox itself, through the CreateOS API or CLI:

The egress field at sandbox create time.
PUT /v1/sandboxes/{id}/egress, which applies live with no restart needed.
The SDK's setEgress method.
The CLI's createos sandbox firewall set <sandbox> <host>.

Rules take a host, host:port, wildcard subdomains, IPs, and CIDRs. In practice, a team using the plugin sets its egress policy on the sandbox template or through the API against the sandboxes the plugin provisions, covering exactly the endpoints the build needs: the package registry, the artifact repository, nothing else. The full mechanics live in the CreateOS docs.

The separation is deliberate. Jenkins owns orchestration. The sandbox platform owns the network boundary. A pipeline change cannot widen the egress policy, because the pipeline has no field to widen it with.

What this gets you and what it does not

What it gets you: a build that downloads a malicious package is a build trapped in a microVM that will be destroyed in minutes, able to reach only the endpoints your policy names, with no shared-host state to poison the next run.

What it does not get you: protection before you set rules. An allowlist you never configure is not a control. The work is writing down which endpoints your builds actually need, and that inventory is usually the same list your security team already wants.

One constraint to name plainly: builds that need broad outbound access, for example pulling from many unmanaged hosts, will need a wider rule set, and a wider rule set is a weaker boundary. The policy is only as tight as the endpoint inventory behind it.

Frequently Asked Questions

Does each Jenkins build really get its own VM? Yes. The plugin provisions a fresh Firecracker microVM agent per build and destroys it when the build finishes. Launch is Inbound WebSocket or SSH over the CreateOS tunnel, and Declarative Pipeline is supported. See the plugin page.

Do I configure the network allowlist in the Jenkins plugin? No. The plugin's Sandbox Template has no egress field. The allowlist is set on the sandbox through the CreateOS API or CLI, for example PUT /v1/sandboxes/{id}/egress or createos sandbox firewall set.

Is outbound traffic blocked by default? No. A sandbox with no egress rules has open outbound access. Deny-by-default starts once at least one rule is set; after that, everything else is denied. Inbound is closed by default regardless.

Can a compromised build bypass the allowlist? The allowlist is enforced in the host kernel with eBPF, outside the guest. A build that is fully compromised inside its microVM cannot change the policy, because the enforcement point is not inside the machine it controls.

Start with one build

Pick the pipeline that touches the least trusted code, install the plugin, and set an egress allowlist on its sandboxes through the API or CLI. If the build still passes with three outbound endpoints instead of the whole internet, you have learned something about your dependency graph that no scanner would have told you. CreateOS Sandbox pricing is per-second with $0 egress, and you can start free with 500 credits 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.