Topic 7

Sandboxes, and module wrap-up

Some agents have to run code: data analysis, coding assistants, agents that write their own tools. AI Engineering (Ch. 6, "Capability extension") calls code interpreters powerful and warns they come with the risk of code injection attacks. You can't make arbitrary code safe by reading it first, so you contain where it runs.

Predict first

A coding agent runs the tests it writes. Where should they run?

On the developer's laptop, with their credentialsIn production, to be realisticIn a sandbox: an isolated container or VM with no production credentials, limited network access, and a disposable file systemNowhere: never run agent code

A bounded agentStep 1 / 5

Scroll sideways to see the whole diagram

At the centre, the model makes the judgment calls.

Text version

At the centre, the model makes the judgment calls.
Its tools set what it can do at all.
A policy in code decides, for each proposed action, whether it runs, waits for a person, or is refused.
Limits stop runaway loops before they cost too much.
Untrusted code runs contained, and traces record everything for lesson 5's evaluation. Autonomy is whatever is left inside these walls.

A sandbox bounds what code can reach: no secrets inside it, network access only to what's needed (or none), resource and time limits, and a fresh environment each time. It's the same idea as everything else in this lesson: decide in advance what the worst step can do, and make that small.

Module wrap-up. Each lesson built part of the harness around the model:

Agents, tools and the loop: the think-act-observe loop, and why reliability lives in the harness.
Workflows or agents: who chooses the next step, and validating plans in code.
State and memory: what the loop carries, and what it must not lose.
When steps fail: timeouts, retries, idempotency and checkpoints.
Traces and evaluation: seeing every step, judging by the end state, measuring consistency.
Bounded autonomy: least privilege, policies in code, limits, untrusted output, and sandboxes.

From this lesson, you can now:

name excessive functionality, permissions and autonomy, and limit each;
set stopping conditions on steps, cost, time and repeated actions, and end runs cleanly;
design narrow tools with least privilege, acting as the user;
enforce a per-action policy in code that checks arguments, not just tool names;
treat tool output as untrusted, and block outcomes rather than detect attacks;
spot and break the lethal trifecta;
run agent-generated code in a sandbox.

Quick check

One sentence for the whole module: how do you make an agent trustworthy?

Assume any step can be wrong, and build the harness so a wrong step is caught, contained and recorded: narrow tools, policies and limits in code, safe retries, and evaluation on the real end stateUse the most capable modelWrite a very detailed promptGive it more tools

Sandboxes, and module wrap-up

Predict first

A coding agent runs the tests it writes. Where should they run?

A bounded agentStep 1 / 5

Scroll sideways to see the whole diagram

At the centre, the model makes the judgment calls.

Text version

At the centre, the model makes the judgment calls.
Its tools set what it can do at all.
A policy in code decides, for each proposed action, whether it runs, waits for a person, or is refused.
Limits stop runaway loops before they cost too much.
Untrusted code runs contained, and traces record everything for lesson 5's evaluation. Autonomy is whatever is left inside these walls.

Module wrap-up. Each lesson built part of the harness around the model:

Agents, tools and the loop: the think-act-observe loop, and why reliability lives in the harness.

Workflows or agents: who chooses the next step, and validating plans in code.

State and memory: what the loop carries, and what it must not lose.

When steps fail: timeouts, retries, idempotency and checkpoints.

Traces and evaluation: seeing every step, judging by the end state, measuring consistency.

Bounded autonomy: least privilege, policies in code, limits, untrusted output, and sandboxes.

From this lesson, you can now:

name excessive functionality, permissions and autonomy, and limit each;

set stopping conditions on steps, cost, time and repeated actions, and end runs cleanly;

design narrow tools with least privilege, acting as the user;

enforce a per-action policy in code that checks arguments, not just tool names;

treat tool output as untrusted, and block outcomes rather than detect attacks;

spot and break the lethal trifecta;

run agent-generated code in a sandbox.

Quick check

One sentence for the whole module: how do you make an agent trustworthy?