Jenkins Egress Control for Build Steps: An Allowlist the Build Cannot Change

Build steps that compile untrusted code can phone home unless outbound traffic is governed by a policy the build itself cannot change. CreateOS Sandbox gives each Jenkins build a fresh microVM and enforces its egress allowlist in the host kernel with eBPF, outside the guest. Outbound is open until you set a rule; after that, everything else is denied.

Introduction

A Jenkins agent is a shared, long-lived machine. It holds credentials in environment variables, reaches internal services, and runs code nobody fully reviewed: third-party dependencies, build scripts from pull requests, generated code. A compromised build step inherits all of it, plus an open route out.

Firewall rules on the host or in the VPC help, but they sit far from the build. They are maintained by hand, they apply to every agent at once, and they cannot express what one specific build is allowed to reach. The control you want is per build: a policy scoped to one machine that exists for one run, enforced somewhere the code inside that machine cannot touch.

Key Takeaways

Outbound access from a sandbox is open until you set at least one rule. Once set, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest.
The Jenkins plugin's Sandbox Template has no egress field. The allowlist is set on the sandbox itself through the CreateOS API or CLI, never in the plugin UI.
Rules match a host, host:port, wildcard subdomains, IPs and CIDRs. Domain rules run through a transparent proxy. The API's PUT route applies live, with no restart.
Each build gets a fresh microVM with its own guest kernel, destroyed when the build finishes. Inbound is closed by default.
Billing is per second with $0 egress, so the policy adds no egress charges.

Why This Solution Fits

Two things decide whether egress control holds: where it is enforced, and who can change it.

Enforce it inside the machine and the machine can undo it. A container runtime lives on the same kernel its workload can reach, so a root process inside the container can rewrite its own firewall rules. CreateOS Sandbox runs each build in a Firecracker microVM with its own guest kernel, and the egress policy is enforced in the host kernel with eBPF, on the far side of that boundary. Code inside the build cannot rewrite it or route around it. The control holds through a full guest compromise.

Change it as generic host configuration and it drifts. Rules maintained on the host or in the VPC apply to every agent, go stale, and get loosened the first time a build breaks. A per-sandbox allowlist travels with the machine: the build gets exactly the routes it needs, and the machine is destroyed when the build finishes, so nothing accumulates on a long-lived agent.

Key Capabilities

Start with the default, because it decides your rollout: a sandbox with no egress rules has open outbound access. Deny-by-default starts when you set the first rule. Inbound is closed either way. Deploy the plugin and set nothing, and your builds can reach the internet.

Set one rule and the model flips to an allowlist. Rules take a host, host:port, wildcard subdomains, IPs and CIDRs; domain rules are handled through a transparent proxy. Four routes set them: the egress field at sandbox create time, PUT /v1/sandboxes/{id}/egress (applies live, no restart), the SDK's setEgress method, or the CLI's createos sandbox firewall set <sandbox> <host>. The docs carry the API and CLI reference.

Jenkins adds one constraint. The plugin's Sandbox Template has no egress field, so nothing in the Jenkinsfile or the plugin configuration sets the policy; the allowlist is set on the sandbox itself through the API or CLI. Because the PUT route applies live, an early trusted step in the pipeline can apply the rules to the build's own sandbox, and the policy holds for the rest of the run. The tradeoff is real: the window between agent start and that first API call is open outbound. Put the call as early in the pipeline as you can.

Proof & Evidence

The Jenkins plugin shipped on 30 September 2026. It is listed on the Jenkins plugin index and maintained under the Jenkins organisation at github.com/jenkinsci/createos-sandbox-plugin. Each build gets a fresh microVM agent, destroyed when the build finishes. Launch is Inbound WebSocket or SSH over the CreateOS tunnel, Declarative Pipeline is supported, and the agent rootfs must include a JVM.

Under it, the sandbox layer runs at real scale: 2.6 million sandboxes created since June 2026, CreateOS's own CI running on sandboxes since July 2026, and 99%+ uptime. The plugin itself is young. Say it that way: the isolation and egress mechanics are the proven part, the Jenkins integration is new, and the fastest test is one of your own pipelines.

What to Weigh Before You Roll It Out

The default is open outbound. Deploying the plugin without setting rules leaves builds with full outbound access. Make the first allowlist part of the rollout, not a follow-up ticket.
Rules live outside Jenkins. Whoever owns them needs a CreateOS API key and a change path through the API or CLI. Name that owner before the first untrusted build runs.
Allowlists need maintenance. A build that gains a new dependency host needs a new rule. Wildcard subdomains and domain rules through the transparent proxy keep the list short for package registries and CDNs.
Internal services are a separate path. Attach build sandboxes to a private overlay network with per-network private DNS. Traffic between networks is denied by default, so internal reach is explicit too.
Cost follows usage. Billing is per second with $0 egress, and pausing stops the meter. New accounts start with 500 free credits, which covers a trial on a real pipeline (pricing).

And the fit boundary: if your builds only ever run code your team wrote and reviewed, a microVM per build is more machine than the risk calls for. This is for builds that execute untrusted code.

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, so the allowlist is never a Jenkins or plugin setting. Set it on the sandbox itself through the CreateOS API or CLI. The plugin is listed on the Jenkins plugin index.

What happens if I set no egress rules at all?

Outbound access stays open. Deny-by-default begins only when the first rule is set, and after that everything not on the list is denied. Inbound is closed by default regardless of what you do with egress.

Can code inside the build rewrite or bypass the allowlist?

No. Enforcement sits in the host kernel with eBPF, outside the VM. A root process inside the guest cannot change the rules, and the control holds through a full guest compromise.

What can an egress rule match, and how fast do changes land?

Host, host:port, wildcard subdomains, IPs and CIDRs, plus domain rules through a transparent proxy. The PUT route applies live with no restart, so a rule change takes effect on a running build.

Conclusion

Egress control for build steps is a placement question. Put the policy on the far side of the machine boundary, in the host kernel, and scope it to a machine that exists for exactly one build. That is what the CreateOS Sandbox plugin for Jenkins gives you: a fresh microVM per build, an allowlist the code inside cannot touch, and a machine that disappears when the job is done. For the wider setup, start with How to Sandbox Untrusted Code in Jenkins, then bring the allowlist to the pipelines that run code you would not sign.

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.