Containing a Compromised Agent Dependency: What to Look for in a Platform

A malicious or vulnerable package inside an agent runtime turns every execution environment that pulled it into a potential incident. The platforms that help most are the ones that make containment fast, make rebuilds cheap, and shrink the window in which exposed credentials still work. This guide walks through what to evaluate, and where CreateOS Sandbox fits.

Introduction

When a dependency in your agent runtime turns out to be compromised, three clocks start at once: containment (stopping the bad code from reaching anything else), rebuild (replacing every environment that ran it with a clean one), and rotation (invalidating every secret that code could have touched).

Traditional infrastructure makes all three slow. Long-lived containers carry state, so "rebuild" means hunting down every instance. Flat networks let a compromised process reach whatever the host can reach. Platforms built for untrusted or agent-written code attack these problems differently. This guide lays out the criteria, then maps scenarios to the choices that follow.

Key Takeaways

Containment depends on isolation boundaries that a compromised guest cannot cross. A Firecracker microVM with its own guest kernel gives you a per-run boundary; a shared container does not.
Egress control is the containment control that matters most during a dependency incident. Outbound access 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. A full guest compromise does not lift it.
Rebuild is cheap when environments are disposable. Fresh microVMs created per run from snapshot, plus pause, resume and fork, mean a clean environment is seconds away, not a ticket away.
Secret rotation is not a sandbox feature. It belongs to your secrets manager. What the execution platform contributes is a short blast radius: short-lived environments, host-enforced egress, and no persistent state for a stolen token to hide in.
Bring-your-own compute and bucket options keep the rebuild inside your own security boundary.

Decision criteria

Evaluate candidate platforms against six criteria. The first three decide whether containment works at all.

1. Isolation boundary. What separates a compromised process from everything else? A microVM with its own guest kernel per sandbox is a boundary a malicious package cannot cross from inside the guest. Containers share the host kernel, so a kernel-level escape takes the whole host with it. Ask specifically: is this VM-isolated with its own guest kernel, or a container with a namespace?

2. Egress enforcement point. Where is the outbound network policy enforced? If it is enforced inside the guest, the compromised code can disable it. If it is enforced on the host, in-kernel, the policy survives a full guest compromise. Also check the default state: outbound access is open until you set at least one rule. A platform that lets you set that rule at create time, update it live without a restart, and scope it to hosts, ports, wildcards, IPs and CIDRs gives you a real containment lever during an incident.

3. Environment lifetime. Long-lived environments accumulate state, and state is where a compromise hides. Per-run environments destroyed when the work finishes shrink the window automatically.

Then three criteria decide how fast you recover.

4. Rebuild mechanics. Can you create a fresh environment from a snapshot in seconds? Can you fork a running sandbox to test a fix without touching the compromised one? Pause and resume let you freeze an environment for forensics instead of destroying evidence.

5. Boundary ownership. Can the rebuild happen inside your own infrastructure? Bring-your-own compute (the same API on your machines) and bring-your-own bucket (your S3, R2 or MinIO) keep artifacts and snapshots inside your perimeter.

6. Cost of standing capacity. During an incident you will spin up many environments at once: clean rebuilds, forensic copies, canary runs. Per-second billing and $0 egress mean the surge does not become a second incident on your cloud bill.

How to choose

Match the scenario you are in to the capability that answers it.

If the compromised dependency is still running somewhere: you need containment first. On a platform with host-enforced egress, set or tighten the allowlist live through the API or CLI, and the rule applies without a restart. The compromised guest cannot remove the rule, because enforcement sits outside the guest. On long-lived containers, containment means killing instances one by one and hoping you found them all.

If you need to know what the bad code did: pause the affected sandbox instead of destroying it. Pause captures a memory-plus-disk snapshot for forensics. Fork it if investigators and a patched rebuild need to work in parallel.

If you are rebuilding affected environments: create fresh microVMs from a clean snapshot. Creation resumes from snapshot in seconds on an idle host, an idle-host figure and not an SLA. A clean environment is faster to create than a container is to audit.

If the dependency could have read secrets: rotate them in your secrets manager immediately, independent of the rebuild. The platform's contribution here is negative space: environments that live for one run, hold no persistent credentials, and cannot reach the network once an allowlist is set. A stolen token that expires before the next run, in an environment that no longer exists, has a very short career.

If the affected workloads run in a regulated environment: use bring-your-own compute so the clean rebuild happens on machines you control, and bring-your-own bucket so forensic snapshots stay in storage you own. Where compliance comes up in procurement, the relevant line is: "We are SOC 2 Type II and ISO 27001 certified, with reports available under NDA."

CreateOS Sandbox is built on exactly these primitives: a Firecracker microVM with its own guest kernel per sandbox, an egress allowlist enforced in the host kernel with eBPF, pause, resume and fork, and bring-your-own compute and storage. The product page covers the isolation and egress mechanics, and the documentation covers the API and CLI routes for setting rules at create time or live. Pricing is per-second with $0 egress; you can start free with 500 credits.

Frequently Asked Questions

Can a sandbox platform rotate my secrets for me? No. Secret rotation belongs to your secrets manager, where the secrets live. What the execution platform contributes is a short blast radius: per-run environments, no persistent state, and egress rules that limit what any stolen credential can reach. Design your rotation so a token exposed during one run is dead before the next run starts.

Does egress restriction come on by default? Outbound access 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. Inbound is closed by default regardless. This distinction matters during an incident: the allowlist is a control you set, not a default you inherit.

How fast can I rebuild after a compromise? Creating a fresh sandbox resumes from snapshot in seconds on an idle host, an idle-host figure and not an SLA. The rebuild is not the bottleneck. Auditing what the compromised code touched usually is, which is why pause and fork matter: freeze the evidence, fork it, and rebuild clean in parallel.

What about CI runners and build agents? The same primitives apply, and there is an official Jenkins plugin. It gives each build a fresh microVM agent that is destroyed when the build finishes, with launch over inbound WebSocket or SSH over the CreateOS tunnel, and Declarative Pipeline is supported. It is listed on the Jenkins plugin index and maintained under the Jenkins organisation on GitHub. Note that the egress allowlist is set on the sandbox itself through the CreateOS API or CLI, not inside the plugin.

Conclusion

A compromised runtime dependency is a test of your execution layer, not just your dependency hygiene. Platforms that help are the ones where containment is a host-enforced rule, rebuild is a snapshot restore, and every environment is disposable by default. CreateOS Sandbox was built for exactly this class of problem: run code you cannot trust, on its own machine per session, with the network policy you set enforced from outside the guest. Pick the platform that makes persistence of a compromise structurally hard, then rotate your secrets on your own schedule, not the attacker's.

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.