There are two kinds of "no" in an agentic system, and they are not the same species.
The first is the model's no: "I shouldn't run that." It is a prediction, produced by the same process that produces every other token, and steered by the same context an attacker can poison. Every jailbreak ever published is the same demonstration repeated: the model's no is a negotiation, and negotiations can be lost.
The second is the operating system's no: Operation not permitted. It is not produced by reasoning. There is no context window to poison, no persona to adopt, no cleverly framed request that makes the kernel reconsider. It is the difference between a guard you can argue with and a wall.
Where each no lives
The model's no lives inside the blast radius. When a poisoned file or tool response rewrites the agent's intentions, the safety instructions are in the same context that just got rewritten. That is the structural weakness of every prompt-level defense: it defends from inside the thing being attacked.
The kernel's no lives below the blast radius. InnerWarden's Execution Gate is an eBPF LSM program: when an unauthorized binary tries to execute inside your agent's environment, the operating system refuses it before a single instruction runs. The rest of the host stays untouched, your agent's legitimate tools keep working, and the denial is logged with the evidence to prove it happened.
You still want the polite layers
None of this makes screening useless, quite the opposite. Command checks catch mistakes cheaply and early, and most days that is all you need: runtime guardrails do the everyday work. The kernel is the layer for the day the polite layers lose the argument. Defense in depth only counts if the deepest layer is one the attacker cannot talk to.
We keep a real, unedited recording of the gate refusing a live attack on the proof page: same binary, runs fine on the host, refused inside the agent's scope. Denied is denied.