Sandboxing an Agent That Executes Code

This report examines a security threat model involving a sandboxed agent that executes code. The code in question is not written by an attacker or a trusted developer, but rather by a model that has read attacker-controlled text. The primary concern is defending against potential accidents, such as destructive commands or scripts that consume excessive resources.

Indirect prompt injections pose another risk, where the agent reads instructions from external sources like web pages or issue comments. Direct abuse is also a concern, as users may prompt the agent to run their own code on the system's infrastructure. To mitigate these risks, the report outlines six critical defenses. Firstly, the container must be isolated from the kernel and cloud metadata endpoints to prevent exfiltration or reverse shell establishment.

Secondly, the container should run with minimal privileges, dropping all capabilities and restricting the user namespace to prevent privilege escalation. Thirdly, egress should be restricted by using a network namespace that does not allow outbound traffic. Fourthly, the bind mount containing the workspace must be carefully monitored, as symlinks and scripts within it could potentially execute malicious code outside the sandbox.

Fifthly, environment variables containing sensitive information should be avoided; instead, credentials should be requested through a secure, audited interface. Lastly, resource limits must be set to prevent prolonged execution or disk space exhaustion. The report emphasizes that while default seccomp profiles provide some protection, they are not sufficient for hosting truly untrusted code.

Implementing a custom allowlist profile tailored to the specific workload is recommended. Additionally, gVisor can provide an additional layer of isolation by interposing a user-space kernel between the workload and the host, reducing the risk of kernel vulnerabilities.