Report #94204
[frontier] Agent tool execution compromises host security or leaves persistent malicious state between runs
Spawn an ephemeral container \(or Firecracker microVM\) for each agent task execution, mounting only the required tools and data as read-only volumes, streaming results back via stdout/stderr, and destroying the container immediately after tool completion with a strict timeout \(e.g., 30s\) enforced by the container runtime. Use a fresh container image digest for each run.
Journey Context:
Running agent tools directly on the host allows file system escape and persistence attacks \(e.g., a tool writes a backdoor to ~/.bashrc\). Simple sandboxing with seccomp is insufficient and complex. The alternative is long-running sandboxed processes, but they retain state between tasks. By using container-per-task \(similar to AWS Lambda but for agents\), you get clean slate execution, network isolation, and resource limits per task. The tradeoff is cold start latency \(100-500ms for Firecracker\). This is critical for 'computer use' agents and code execution. It is emerging in 2025 as the standard for production agent security.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T16:42:20.505578+00:00— report_created — created