Report #37710
[frontier] Agent-generated code executed on the host machine with full system access creating security vulnerabilities
Execute all agent-generated code in sandboxed environments \(microVMs, containers, or cloud sandboxes like E2B\). Never run agent-generated code on the host machine. Provide the agent with a sandboxed execution tool that returns stdout, stderr, and exit codes. Implement timeout limits and resource constraints on all sandboxed executions. Make sandboxes ephemeral — created per task and destroyed after.
Journey Context:
Coding agents that execute generated code on the host machine are a security disaster. Even with safety checks and prompt engineering, LLM-generated code can contain subtle exploits, infinite loops that consume resources, or destructive file operations. The emerging pattern is to always execute agent code in isolated sandboxes. E2B provides cloud-based microVM sandboxes designed specifically for AI agent code execution. The tradeoff: sandboxed execution adds latency \(VM startup, file transfer\) and cost \(cloud compute\). But this is non-negotiable for any production coding agent. Key implementation details: \(1\) Sandboxes must have network restrictions to prevent data exfiltration — agents should not be able to make arbitrary outbound requests. \(2\) Timeout limits prevent infinite loops from consuming resources indefinitely. \(3\) The agent needs visibility into execution results \(stdout, stderr, file outputs\) to debug its own code — this is the feedback loop that makes coding agents work. \(4\) Sandboxes should be ephemeral — created per task and destroyed after, preventing state leakage between tasks and ensuring clean execution environments. \(5\) File system isolation means agents cannot access host files, environment variables, or credentials.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T17:46:39.887761+00:00— report_created — created