Where Should Egress Control for Jenkins Build Steps Live? A Decision Guide

Your build steps run code you did not fully vet: plugins, dependency scripts, generated code. The question is not whether to restrict what that code can reach on the internet, but where the restriction should live so a compromised build cannot simply turn it off. This guide compares the practical options and gives you a decision path.

Introduction

A Jenkins build agent is, by design, a machine that executes arbitrary instructions. Pipeline steps fetch dependencies, run test suites, execute scripts from your repositories, and increasingly run AI-generated code. Every one of those steps makes outbound network calls. Most of them are legitimate. Some are not, and the difference is decided by whatever code is running at the time.

The classic approach is to put the agent inside a network with a firewall or proxy in front of it. That works until the build itself needs to reach something new, someone opens a hole, and the hole stays open. The control ends up being a network-level convention that the build can negotiate around, rather than a property of the machine the build runs on.

There is a third option worth taking seriously: run each build on a fresh microVM whose outbound access is governed by an allowlist enforced outside the guest. This guide walks through the decision criteria, then maps common scenarios to a choice.

Key Takeaways

Egress control for build steps is a question of enforcement location: network appliance, host kernel, or inside the guest. Enforcement inside the guest is the weakest option because the code you are restricting is also the code controlling the machine.
An allowlist enforced in the host kernel, outside the guest, survives a full guest compromise. That is the property to aim for.
Default posture matters. Outbound access is open until at least one rule is set; once set, everything else is denied. Do not assume a fresh environment is locked down before you configure it.
For Jenkins specifically, the CreateOS Sandbox plugin gives each build a fresh microVM agent, but the egress allowlist is not a plugin setting. It is set on the sandbox itself through the CreateOS API or CLI.
Decide by three criteria: can the build change the rule, does the rule survive compromise, and how fast can you grant a legitimate new dependency access.

Decision Criteria

1. Can the workload change the rule? If the enforcement point runs inside the same operating system as the build, a build step with enough privilege can alter or bypass it. iptables rules on the agent, an HTTP proxy configured in environment variables, or an allowlist file in the image all fail this test. Enforcement that sits in the host kernel, outside the guest, does not: the guest has no path to it.

2. Does the control survive compromise? Assume a malicious dependency gets code execution inside the build. What can it do? If enforcement is host-side, it can reach only the hosts on the allowlist, and it cannot remove the allowlist. If enforcement is guest-side, it can do whatever the build user could do, which usually includes disabling the control.

3. What is the default posture before you configure anything? This is where teams get burned. On CreateOS Sandbox, for example, a sandbox with no egress rules set has open outbound access. Deny-by-default only starts once at least one rule exists. Inbound is closed by default regardless. Any solution you evaluate: check what happens before you write a rule, not just after.

4. How quickly can you grant legitimate access? Egress control that makes every new dependency a two-week ticket gets quietly disabled. Look for rules that apply live without a restart, and that accept host, host:port, wildcard subdomains, IPs and CIDRs.

5. Does each build start clean? A long-lived agent accumulates state: cached credentials, installed tools, whatever the last build left behind. A fresh machine per build shrinks the blast radius of any single compromise and makes the egress policy the only persistent control that matters.

How to Choose

If your builds are fully trusted and internal only, a network-level firewall or proxy in front of a static agent pool is often enough. The threat model is misconfiguration, not malicious code. Keep the rule set small and reviewed.

If your builds pull third-party dependencies, run plugins, or execute generated code, guest-side controls are no longer sufficient. Move enforcement outside the guest. Two paths:

Network appliance in front of a static agent. You keep your current Jenkins setup and add a firewall or egress proxy at the subnet boundary. The rule survives compromise of the agent, but it is coarse: it applies to the whole subnet, and any agent on that subnet shares the same reach. Opening access for one build opens it for all of them.
Per-build microVM with a host-enforced allowlist. Each build gets its own machine, its own guest kernel, and its own egress rules enforced in the host kernel with eBPF. Rules are set on the sandbox through the CreateOS API or CLI: the egress field at create time, PUT /v1/sandboxes/{id}/egress (applies live, no restart), the SDK's setEgress method, or createos sandbox firewall set <sandbox> <host> on the CLI. This is the model behind CreateOS Sandbox.

If you are on Jenkins and want the per-build microVM model, the official CreateOS Sandbox plugin provisions a fresh microVM agent per build and destroys it 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. The source lives under the Jenkins organisation at github.com/jenkinsci/createos-sandbox-plugin.

One thing to get right: the plugin's Sandbox Template has no egress field. The allowlist is never configured inside Jenkins or the plugin UI. Set it on the sandbox itself through the CreateOS API or CLI, and keep that rule set in version control next to your pipeline so a change to what builds can reach is a reviewed change.

If your builds handle regulated data or must stay inside your own boundary, bring-your-own compute matters as much as egress. CreateOS runs the same API on your own machines, so the isolation and egress model holds while the workload stays in your infrastructure. See the product documentation for the self-host topology.

If you cannot state what each build should reach, start there before choosing tooling. Write the allowlist per pipeline: package registries, your artifact store, specific test endpoints. The list itself is the deliverable; the enforcement mechanism is the easy part once the list exists.

Frequently Asked Questions

Does the CreateOS Sandbox plugin let me configure the egress allowlist in Jenkins? No. The plugin's Sandbox Template has no egress field. The allowlist is set on the sandbox itself through the CreateOS API or CLI, not through Jenkins or the plugin UI. Install the plugin from Manage Jenkins > Plugins > Available plugins; you need a CreateOS API key, which you can create free at createos.sh.

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

Where is the egress allowlist actually enforced? In the host kernel, outside the guest, using eBPF. The build and anything compromising it have no path to the enforcement point, so the allowlist survives a full guest compromise.

What do egress rules accept? Host, host:port, wildcard subdomains, IPs and CIDRs. Rules set via PUT /v1/sandboxes/{id}/egress apply live without a restart, so granting a legitimate new dependency does not require rebuilding the agent image.

Conclusion

The decision comes down to enforcement location. Controls inside the guest are suggestions to whatever code is running. Controls at the subnet boundary are real but coarse. A per-build microVM with an allowlist enforced in the host kernel gives you both properties at once: the rule survives compromise, and it is specific to a single build.

For Jenkins, the path is concrete. Install the CreateOS Sandbox plugin, give each build a fresh microVM agent, and set the egress allowlist on the sandbox through the API or CLI, kept in version control beside the pipeline. Start with the allowlist per pipeline, then let the enforcement mechanism carry 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.

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.