Managed hands: Code Interpreter and Browser

Two capabilities separate an agent that knows from an agent that does: running code it just wrote, and operating a browser on the live web. They are also, not coincidentally, the two most dangerous things an agent does, because both execute the untrusted: code authored by a model that read hostile input, and web content authored by strangers. The concepts chapter's isolation ladder said such things belong behind VM-grade walls; this chapter looks at the session-shaped sandboxes the platforms sell for exactly this, with AgentCore's pair as the worked example and the wider ecosystem as the frame.

Why these two tools keep appearing

Every mature agent stack grows a code-execution surface, for a reason worth stating precisely: code is how an agent escapes the token economy. Reading a 100,000-row spreadsheet through the context window costs a fortune and loses precision; writing twenty lines of pandas and reading back the summary costs almost nothing and is exact. Analysis, file transformation, chart generation, data validation, everything the gallery's document and audit systems do at volume, wants to be computed, not prompted. The same logic produced Anthropic's code-execution tool, the sandbox startups (E2B, Modal and kin), and AgentCore Code Interpreter: give the model a real interpreter, in a room built for the assumption that its code cannot be trusted.

The browser earns its place differently: it is the tool of last resort for the software that has no API. Portals, legacy back offices, supplier sites, the whole browser-automation use case. A browsing agent perceives pages and acts on them (click, type, navigate), which means arbitrary web content streams straight into model context: the textbook injection vector, in a tool whose entire job is to visit places you do not control.

AgentCore's pair, decoded

Both follow the pattern the runtime chapter established: session-scoped, isolated, serverless, per-second.

Code Interpreter gives an agent a stateful interpreter session (Python and friends, file uploads in, artifacts out) inside a dedicated microVM. Statefulness matters agentically: the model can load data in one turn, inspect intermediate results, and refine across the conversation, the way a human uses a notebook. The security posture is the ladder's top rung by default: hardware-virtualized isolation per session, controllable network access (the "agent wrote a bitcoin miner" and "agent exfiltrates via curl" failure modes are network policy questions, and the answer should usually be no egress), and teardown with the session.

Browser is a managed headless browser fleet with the same session model: the agent (or a model built for the job) drives; the platform runs the browser far from your infrastructure, records the session, and keeps an audit trail. Two decoded details worth carrying: AWS's own browser-driving model, Nova Act, executes its actions through Playwright (the open-source automation framework), the same judgment-from-a-model, hands-from-open-source split as everywhere else in this stack; and the reason the browser runs inside the sandbox boundary rather than beside it is injection: whatever a hostile page convinces the agent to do, it does inside a disposable, egress-limited room, as an identity that (per the Identity chapter) carries only the credentials the task was granted.

Don't be confused: Code Interpreter vs a Lambda tool host. Both "run code for the agent," and they answer opposite trust questions. A Lambda tool host runs your code: you wrote query_metrics, you deploy it, the model merely chooses when to invoke it. Code Interpreter runs the model's code: authored at runtime, untrusted by construction. Your code needs ordinary service hygiene; the model's code needs a cell. Confusing the two directions, most often by letting model-authored code execute inside a trusted tool host, is how an agent's request becomes your incident.

Buy, build, or borrow

Part 5 will build the DIY alternative (Firecracker, warm pools, snapshot restore, an API in front) precisely so the buy decision is informed rather than faith-based. The preview of that chapter's conclusion, honestly stated:

The default this book recommends: buy first. A managed microVM sandbox on day one beats the container-with-good-intentions most teams would otherwise ship, and the switching cost later is low because the interface (run code, get results; drive page, get observations) is narrow. Build when a hard requirement forces it: egress policy the product cannot express, exotic images, fleet-scale economics, or regulatory placement. That is also why Hive's architecture drew the sandbox as its own plane with the implementation swappable behind it.

👉 Next: watching and governing the managed agent: traces, the policy engine that models cannot argue with, and graders over trajectories.