[leodido]

Ah, and thank you for pointing to `fapolicyd`! It's the closest prior art to what we're doing at the exec layer, and its `ld.so` bypass prevention via policy rules addresses the exact dynamic linker evasion I wrote about.

Two architectural differences worth noting, which I guess you are already aware of. First, `fapolicyd` is a userspace daemon... The kernel blocks until the daemon responds. This works, but the daemon itself becomes a single point of failure, isn't it? If it stalls or is killed, the system either deadlocks or fails open (hence the deadman's switch). Veto keeps hash computation and enforcement inside the BPF LSM hook. The BPF program can't (hopefully lol) crash and requires no context switch for the decision.

Second, `fapolicyd` defaults to an allowlist model: anything requesting execution must be in the trust database. That's a stronger default posture than our current denylist. We're starting with denylist because it's the lower-friction entry point for teams adopting agent security incrementally: you block known things without having to enumerate all good things first. In 2 words: different tradeoffs.