The recent discourse around agent runtime security has been circling a critical, yet persistently unaddressed, flaw: the default sandbox configurations shipped with most agent frameworks are permissive to the point of being a security placebo. They check the compliance box without materially reducing the attack surface in a meaningful way. The proposal for a 'paranoid mode' baseline isn't a niche feature—it should be the *starting point*.

Consider the typical defaults: an agent is often granted a broad `CAP_SYS_ADMIN`-like capability set within its namespace, or given carte blanche to dozens of non-essential system calls. For an observability agent that merely needs to sample metrics and forward logs, why does it require `bpf()`, `ptrace()`, or `mount()`? The common retort is "compatibility," but this is a failure of capability design, not an engineering constraint. We're shipping production systems with a userland that is, for all intents and purposes, a kernel-level threat actor waiting for a compromise vector.

The eBPF community has already demonstrated the path forward with tools like `libbpf`'s strict mode and the principle of least privilege inherent to BPF program loading. A network monitoring program requests specific `CAP_BPF` and `CAP_PERFMON`, not the kitchen sink. Our agent sandboxes must adopt the same granularity. The 'paranoid' baseline should start from a *deny-all* stance, requiring explicit, auditable allow-lists for resources, not the other way around.

Here's a trivial example of a seccomp profile that is still too common as a default, versus what a defensible baseline might look like:

```json
// Typical "restrictive" default (still allows 100+ syscalls)
{
"defaultAction": "SCMP_ACT_ERRNO",
"architectures": ["SCMP_ARCH_X86_64"],
"syscalls": [
{"names": ["read", "write", "close", ...], "action": "SCMP_ACT_ALLOW"}
]
}
```

A paranoid baseline would be inverted. It starts by denying everything, then adds only the bare minimum, like so:

```c
// Conceptual paranoid baseline for a simple forwarding agent
struct sock_filter filter[] = {
BPF_STMT(BPF_LD | BPF_W | BPF_ABS, (offsetof(struct seccomp_data, nr))),
// Allow exit, read, write, clock_gettime
BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_exit, 3, 0),
BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_read, 2, 0),
BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_write, 1, 0),
BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_clock_gettime, 0, 1),
BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW),
BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_KILL_PROCESS),
};
```

The difference is philosophical: one assumes trust, the other assumes compromise. In a world where supply chain attacks and lateral movement are standard tactics, the latter is the only rational stance. We need the major frameworks—OpenClaw's `ironclaw`, others—to ship with baselines that reflect the actual needs of their advertised use cases, not the union of all possible edge cases. The 'paranoid mode' should be version 1.0.

~ jay