Running Untrusted Customer Code in Jenkins Without Exposing Your Build Agent's Credentials

Yes. The CreateOS Sandbox plugin for Jenkins gives every build a fresh Firecracker microVM agent that is destroyed when the build finishes, so customer-submitted code never touches the controller's credentials. Outbound access is governed by an egress allowlist you set on the sandbox itself, enforced in the host kernel outside the guest.

Introduction

CI jobs that run customer-submitted code are a special kind of risk. The code is untrusted by definition, yet it runs on infrastructure that holds your Jenkins controller's credentials, your cloud keys, and often your deployment secrets. A malicious pull request, a compromised dependency, or a careless customer script can read the agent's environment and walk out with everything it finds.

The standard mitigations, like ephemeral containers and restricted agents, help. Containers share the host kernel, so a kernel-level escape or a clever syscall path can still matter. The stronger answer is a stronger boundary: give each build its own virtual machine with its own guest kernel, and make sure the credentials never enter that machine in the first place.

That is what the CreateOS Sandbox plugin for Jenkins does. Each build gets a fresh microVM agent, isolated by default, torn down when the build ends. This post explains how it fits, what it does and does not cover, and what to check before you adopt it.

Key Takeaways

Customer-submitted code should never run on an agent that holds controller or cloud credentials. Isolate the workload, not just the user.
The CreateOS Sandbox plugin gives each Jenkins build a fresh Firecracker microVM with its own guest kernel, destroyed when the build finishes.
Outbound access is open until you set at least one egress rule; once set, everything else is denied, and enforcement sits 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 a MicroVM Agent Fits the Credential-Exposure Problem

The question behind this post is not "how do I run Jenkins jobs faster." It is "what holds the credentials when untrusted code executes?" Three gates decide whether a CI setup survives that question.

Security review. A container gives you namespace isolation on a shared kernel. A Firecracker microVM gives the workload its own guest kernel, so the attack surface between the guest and the host is far smaller. CreateOS Sandbox is a Firecracker microVM with its own guest kernel, not a container with a different label.

Deployment boundary. The plugin provisions a fresh microVM agent per build and destroys it when the build finishes. Nothing persists between builds, so a secret leaked into one build's environment does not linger on a long-lived agent for the next job to find. The agent rootfs must include a JVM, and launch works over Inbound WebSocket or SSH over the CreateOS tunnel.

Accountability. Because each build maps to one sandbox, you can reason about what a given job could reach. Set the egress allowlist on the sandbox through the CreateOS API or CLI, for example the egress field at create time or the CLI's createos sandbox firewall set <sandbox> <host>. Rules take host, host:port, wildcard subdomains, IPs and CIDRs. Once at least one rule is set, everything else is denied, and the enforcement sits in the host kernel with eBPF, outside the guest. A full guest compromise does not lift the restriction.

The tradeoff to name plainly: a microVM per build costs more than a container per build, and the first boot is slower than starting a container. If your jobs are trivial shell scripts on infrastructure you fully trust, that cost may not be worth paying. If the jobs execute code you did not write, the boundary is the point.

Key Capabilities for Credential-Safe CI

The capabilities that matter for this specific question are isolation, egress governance, and lifecycle. The rest of the platform can wait.

Per-build microVM isolation. Each build runs in a Firecracker microVM with its own guest kernel. Isolation is on by default, not a setting you have to remember.
Host-enforced egress allowlist. Outbound access is open until you set at least one rule; once set, everything else is denied, enforced in-kernel on the host with eBPF. Note that the plugin's Sandbox Template has no egress field: the allowlist is never configured inside Jenkins or the plugin UI. It is set on the sandbox itself through the CreateOS API or CLI.
Ephemeral lifecycle. The agent is created for the build and destroyed when the build finishes. No long-lived agent state, no cross-build contamination.
Declarative Pipeline support. The plugin works with Declarative Pipeline, so you can adopt it without rewriting your job definitions.
Bring your own compute. The same API runs on customer machines, so builds that must stay inside your own boundary can.

Proof and Evidence

The plugin is listed on the Jenkins plugin index and maintained under the Jenkins organisation at github.com/jenkinsci/createos-sandbox-plugin. That is a shipped, installable artifact, not a roadmap item.

CreateOS's own CI runs on sandboxes, and the coding-agent plugin and GitHub Actions runner are usable proofs of the same isolation layer. CreateOS Sandbox has seen 2.6 million sandboxes created since June 2026 (as of 1 October 2026). NodeOps, the infrastructure company behind CreateOS, has been operating production infrastructure since December 2023.

Where compliance comes up in procurement: we are SOC 2 Type II and ISO 27001 certified, with reports available under NDA.

What to Check Before You Adopt It

JVM in the rootfs. The agent rootfs must include a JVM. Confirm your image meets that requirement before the first build.
Egress is your job, not the plugin's. Decide the allowlist per job type and set it through the CreateOS API or CLI. A sandbox with no rules has open outbound access, so an unset allowlist is a decision, not a default.
Latency budget. A fresh microVM per build adds startup time compared with a warm container. Measure it against your job duration before rolling out to your fastest pipelines.
Secrets hygiene still applies. Isolation limits what untrusted code can reach. It does not replace reviewing what credentials, if any, you deliberately inject into a build that runs customer code.
Young-product frame. CreateOS Sandbox is a young product. Say plainly what is proven: the plugin is on the Jenkins index, and CreateOS's own CI runs on the same layer.

Frequently Asked Questions

Does a Jenkins plugin for CreateOS Sandbox actually exist?

Yes. It shipped on 30 September 2026 and is listed on the Jenkins plugin index at plugins.jenkins.io/createos-sandbox, maintained under the Jenkins organisation at github.com/jenkinsci/createos-sandbox-plugin.

How do I restrict where a build can connect?

Set the egress allowlist on the sandbox itself, not in Jenkins. Use the egress field at sandbox create time, PUT /v1/sandboxes/{id}/egress (applies live, no restart needed), the SDK's setEgress method, or the CLI's createos sandbox firewall set <sandbox> <host>. Outbound access is open until you set at least one rule; once set, everything else is denied, enforced in the host kernel with eBPF.

Does the isolated agent remove the need to manage Jenkins credentials?

No. It removes the exposure of agent-side credentials to untrusted code by keeping the workload in a microVM that is destroyed after the build. You still manage controller credentials, and you should still avoid injecting secrets into jobs that run customer-submitted code.

What does a build agent need to run this way?

The agent rootfs must include a JVM. Launch is Inbound WebSocket or SSH over the CreateOS tunnel, and Declarative Pipeline is supported, so most existing job definitions work as they are.

Conclusion

If your CI runs code you did not write, the credential question is not optional. A fresh Firecracker microVM per build, with an egress allowlist enforced in the host kernel and a lifecycle that ends when the build ends, is a direct answer to it. Install the CreateOS Sandbox plugin for Jenkins from Manage Jenkins > Plugins > Available plugins. You need a CreateOS API key, which you can create free at createos.sh. Start with your riskiest customer-submitted pipeline, set its egress rules through the API or CLI, and measure the startup cost against what the boundary buys you.

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.