Shrinking an agent's blast radius: per-session tool allowlist + gVisor sandbox (open source, honest limits)

A few days ago I posted here about the governance kernel on my open-source agent (Chimera). The comments were sharper than the post — two of them turned into features I shipped this week. Both, plus where they still fall short. Per-session tool allowlist. Before, any tool registered for a run was reachable; the kernel only gated per-action. Now a session gets an explicit grant: --allow-tools read_file,grep,glob gives a read-only run, and everything else is dropped from the registry — it never reaches the model's schema, so the agent can't be talked into calling what it wasn't given. Composes with the per-action kernel (restrict the grant, then gate the survivors); subagents inherit it. gVisor runtime for the sandbox. The docker sandbox was a plain container, and a container isn't a VM — an escape usually rides a host-kernel bug. CHIMERA_SANDBOX_RUNTIME=runsc now runs it under gVisor, whose userspace kernel intercepts the container's syscalls and shrinks that host-kernel surface. Drop-in OCI runtime, so it's one env var, not a rewrite. The honest limits (this crowd rightly hates overclaiming): The allowlist defaults to unrestricted for backward-compat — you opt into locking a session. gVisor is opt-in, needs gVisor on the host (Linux), and still isn't a full VM; a real microVM is the ceiling. Neither touches the actual hard problem: an agent can't reliably tell data from instructions, so a malicious page talking it into rm-ing the project walks past all of this. Tracked, still open — this shrinks the blast radius, it doesn't close the door. Apache-2.0, ~568 tests. Repo link in a comment (sub rule). Both came from commenters on the last thread (u/zoharel on both). If you've built session-scoped capability grants or syscall-level sandboxing for agents, I'd like to hear what held up in practice.