Locking the box: egress, secrets, and quotas

A microVM stops the agent's code from escaping to the host. It does nothing, by itself, about the code phoning home, mining cryptocurrency on your dime, exfiltrating the data it was handed, or wedging on an infinite loop. Isolation is a wall around the box; this chapter is about what the box is allowed to do from inside it. These controls matter more than the wall for the failure modes agents actually hit, because the common case is not a VM escape (rare, hard) but a sandbox doing exactly what its walls permit, in service of an attacker.

Egress is the control that matters most

Ask what the poisoned-PDF script from Chapter 28 actually needs to hurt you. Almost always: a network path out. To email the database, it must reach a mail server. To exfiltrate, it must reach an attacker endpoint. To mine, it must reach a pool. Cut outbound network and most of the damage an escaped-instruction script can do evaporates, because the data it stole has nowhere to go and the resources it wants to abuse are unreachable.

So the default for a code sandbox is stark and correct: no network at all. Analysis, transformation, computation, the overwhelming majority of what agents run code for, need no egress whatsoever. When a task genuinely needs the network (installing a package, calling one API), the answer is not "turn networking on" but an allowlist proxy: the microVM's only route out is a proxy that permits a named set of destinations and refuses the rest, logging every attempt. The package installer reaches the package index and nothing else; the data-analysis box reaches nothing.

Decoded onto the build, egress control is a networking choice at the microVM's tap device: no tap, no network; or a tap routed only through the filtering proxy. Decoded onto the managed services, it is the reason a sandbox product's network options are a security feature you evaluate, not a convenience, and the reason Chapter 31 lists "egress policy the product can express" as a top build-trigger: a managed sandbox whose egress you cannot lock to an allowlist may not be lockable enough for hostile input.

Secrets live outside the box

The second rule follows from assuming the box is compromised: a secret the sandbox can read is a secret the attacker has. Therefore the sandbox holds none. Not in an environment variable, not in a mounted file, not passed in with the code.

This sounds limiting until you notice it is the exact pattern the Identity chapter already established for tools, now applied to the sandbox. When sandboxed code must make an authenticated call, it does not get the credential; it makes an unauthenticated request to the allowlist proxy, and the proxy (outside the box, trusted) attaches the credential at egress. The sandbox proves what it wants to do; the trusted layer decides whether its authority permits it. That "credentials injected at the boundary, never inside" is the same convergent design as AgentCore Identity's token vault and Anthropic's egress substitution, and it is the same reason: any secret placed where hostile code can read it is already lost.

Quotas stop the boring attacks

Not every failure is malicious; some are just runaway. An agent's code can loop forever, fork-bomb, allocate until the host swaps, or fill the disk. The microVM's own configuration is the backstop, and it is cheap:

• Wall-clock timeout, enforced by the execution harness and by the manager destroying the microVM after a hard deadline. Belt and suspenders, because the in-VM timeout is inside the thing you do not trust.
• Memory cap, which the microVM has natively: it was booted with a fixed memory size, so it physically cannot exceed it. A container needs a cgroup to get what a microVM gets for free.
• CPU cap, via the microVM's vCPU count and the host's scheduler.
• Disk quota on the writable scratch area, which dies with the microVM regardless.

These turn the "agent wrote a bitcoin miner" and "agent's code hung" failure modes into bounded, logged, self-cleaning events instead of host incidents.

Log from outside, not inside

A closing principle that trips up first designs: observe the box from the trusted side of the wall. Logs written by the sandboxed code are attacker-controlled, so treat them as untrusted input (display them, do not act on them). The trustworthy record is what the trusted layers saw: the manager's record of what was run and for how long, the proxy's record of every egress attempt (allowed and denied), the resource meters. When you investigate a sandbox incident, the proxy's egress log is the first artifact you want, and it exists only if you built egress to flow through a point you control, which is one more reason egress is the chapter's spine.

The controls, mapped to the failures

Read the table top to bottom and the layering is clear: the wall stops escape, egress control stops damage, secret-exclusion stops theft, quotas stop abuse, external logging stops concealment. Isolation is one row of five, and a design that has only that row has, at most, a very well-isolated way to get exfiltrated.

Don't be confused: sandboxing vs guardrails. Guardrails (Chapter 13) inspect content, the text going into and out of the model, and try to catch bad intent before it acts. Sandboxing bounds capability, what the agent's code can reach once it acts, and assumes intent-detection sometimes fails. They are complementary and neither replaces the other: guardrails reduce how often you rely on the sandbox, the sandbox caps the damage when guardrails miss. A system with guardrails and no sandbox is betting its blast radius on a classifier, which gate 11 of the production bar forbids.

👉 Next: buy, build, or borrow, the part's verdict: the managed sandbox, the DIY service you just costed, and the container-with-hardening middle path, scored on the axes that actually decide it.