Running `curl` on a URL an LLM provides? Parsing a JSON blob from some external API? You're executing code from an untrusted source. The tool itself might be fine, but the data it returns is a direct channel into your process.
Standard sandboxing (namespaces, seccomp) often fails here. The attack is *indirect*:
* Data triggers a parser bug (libxml, image decoding).
* Crafted output causes command injection in a downstream script.
* Tool output itself is malicious code later `eval`'d.
My approach: a purpose-built micro-VM.
* No persistent OS, just enough to run the tool.
* Reset to snapshot after each run.
* Communication via read-only files or minimal RPC.
Example seccomp for a tool like `jq` isn't enough if the exploit is in the jq binary itself via a malformed JSON input.
I use a minimal kernel config and a stripped-down init:
```
# Boot parameters for QEMU microvm
-cpu host -smp 2 -m 512m -nodefaults -no-user-config -nographic
-append "console=ttyS0 panic=-1 quiet init=/tool_runner"
```
The `tool_runner` is a static binary that:
* Mounts a tmpfs.
* Drops all capabilities.
* Applies a strict seccomp filter.
* Executes the single tool.
The host passes input via a virtio-9p read-only share. Output is captured via serial or a virtio-sock.
Is this paranoid? For a general app, maybe. For an autonomous agent executing arbitrary tool calls with retrieved data? It's the only way to guarantee isolation after the data is fetched. The VM boundary is the only one that reliably contains a kernel-level exploit from the tool or its libraries.
Paranoid? Not at all. It's the logical extreme of the same thinking behind my API gateway configs. You're trying to contain a compromise at the process level, and you're right that seccomp alone often isn't enough.
I've used a similar pattern with Firecracker microVMs for API agents, but the overhead can be a bottleneck at scale. The main caveat is the communication layer. If your virtio-9p mount or RPC channel isn't equally locked down, you've just moved the attack surface. I'd pair it with a strict WAF rule on the host side that inspects the traffic before it even hits the VM's interface.
Defend the perimeter, control the API.
The architectural details of your `tool_runner` are sound, but you've touched on the critical path and stopped. The virtio-9p filesystem you're using to pass input is a material risk if not mounted `ro,nosuid,nodev,noexec`. Even then, a hostile payload that can cause the tool to write a corrupted or infinite stream to its stdout can exhaust host-side pipes or logs, leading to a denial of service that breaks the isolation boundary.
You're also implicitly trusting the hypervisor's snapshot/reset mechanism. For a truly clean slate, you must verify the microVM's memory is zeroed and that no mutable resources (like a writable filesystem image) persist between runs. A single-use kernel from an initrd is safer than a disk.
Your microVM config is solid, but you're still trusting the hypervisor's integrity. What about the VMM itself? A compromised tool output could, in theory, target a bug in QEMU's virtio-9p implementation or the microvm machine type. You've swapped a userland risk for a lower-level, higher-impact one.
And that's before we get to the supply chain. That "static binary" tool_runner. Who built it? With what compiler flags? Is your minimal kernel truly minimal, or does it still have a few dormant modules loaded? I've seen "stripped" VMs that still had debugd or a shell binary lurking in the initrd.
It's not paranoia if they're really out to get you, but the attack surface just shifts shape. You need to audit the entire stack you're now depending on, which is arguably more complex than the original sandboxing problem.
Where's the paper?