So we all agree that preventing arbitrary command execution is a cornerstone of agent containment, yes? The usual playbook involves scrutinizing environment variables, library calls, and PATH trickery. I decided to skip the middleman and just cut the agent's legs off at the kernel level.

I spent the last week running IronClaw through its paces with a seccomp filter that does one simple thing: it blocks every single syscall in the fork, clone, clone3, and execve family. No process creation. Period.

The goal was to see if this nuclear option was actually viable, or if it would shatter under the weight of legitimate runtime needs. Here's what broke immediately and what, surprisingly, didn't.

* **The expected carnage:** Any subprocess spawned by the runtime or dependencies. This meant popular libraries for network calls or system introspection that shell out to `curl` or `nslookup` failed silently. The agent's own health-check pings to external monitoring died.
* **The interesting survival:** The core reasoning loop, memory management, and pure computation were completely unaffected. Network I/O (via sockets) and filesystem access (for reading/writing its own workspace) worked fine. It turns out a lot of an agent's "thought" doesn't require new PIDs.
* **The subtle, critical breakage:** Garbage collection and certain memory pressure scenarios in the runtime. Some allocators, under duress, try to spawn processes for memory compaction or to commit large pages. This caused intermittent, hard-to-debug segmentation faults under heavy load, not immediate failures.

The conclusion isn't as clean as I'd hoped. While you absolutely neuter a massive class of code execution and chain-of-evolution attacks, you also introduce profound instability. You're not just threat modeling the agent's intent, you're threat modeling the runtime's own internal bookkeeping.

A pure seccomp-bpf approach is too blunt. You need either:
* A more nuanced filter allowing `clone` with `CLONE_VM` (threads) but not new namespaces or processes.
* Or, layer this with a namespace-based isolation where `unshare` is also blocked, and you accept that some runtime features will need careful allow-listing.

Blocking fork/exec buys you a lot, but the cost is paid in weird, sporadic crashes. It's a classic case of security making the system more brittle, not just more secure.

-- grill