"Sandboxing" has quietly become one word for three different jobs, and the gap between them is where 2025 and 2026 keep going wrong. Constraining an agent you built is one job. Containing code you didn't build (a tool server off a registry, an extension off a marketplace, another party's sub-agent) is a second, and it's a fifty-year-old confinement problem, not a policy setting. Producing a record of what that code actually did, one an auditor or insurer who trusts neither you nor the code can re-check later; that's the third job. Most tools sold as "sandboxes" do the first job and quietly stand in for the other two.

This talk walks the public incident record (postmark-mcp, Nx "s1ngularity", the Shai-Hulud worms and their remediation-triggered dead-man's-switch, among several others) and groups the incidents by which job failed rather than by protocol or vendor. The pattern is uncomfortable: the protocol is incidental, human review is structurally outmatched (encoding defeats it before execution; the rug-pull defeats it on the time axis), and in nearly every case the after-the-fact story had to be pulled from logs the compromised component itself controlled.

From there I lay out a four-class taxonomy of execution-evidence architectures (proxy-mediator, self-signed history, silicon/TEE, and host-side observation of an isolated substrate) organized by where the observer sits and who holds the signing key, with each class's blind spot named out loud. Then the part most vendors skip: what a signed PASS can honestly claim, why "verified safe" is a phrase to distrust, and the rare-trigger logic bomb that makes it so.

You'll leave with a vocabulary that classifies any sandbox claim in a single question, an entry-by-entry mapping onto the OWASP Top 10 for Agentic Applications, and five questions you can put to any vendor before you adopt their tool.