Prompt injection is not the attack. It is the first step of one. The attack finishes on the host, as a system call the kernel was asked to make. If you only defend the first step, you are guarding the doorway while the intruder walks out the back with the silver.
The whole chain is worth walking slowly, because each link tells you where a defense can and cannot stand.
The chain, one link at a time
Step one: poisoned input. Something enters the agent's context that the agent treats as trustworthy. It might be an injected instruction in a web page the agent fetched, the output of a tool the agent called, or a file the agent was asked to read. The source does not matter. What matters is that the model cannot reliably tell data from instructions, so the poisoned text gets read as intent.
Step two: intent rewrite. The agent, still behaving exactly as designed, updates its plan. It was summarizing a document a moment ago. Now it "needs" to read ~/.aws/credentials, or exfiltrate a file, or run a helper script it just wrote. From the inside, this looks like normal reasoning. That is the trap: the rewrite is indistinguishable from legitimate planning, because it uses the same machinery.
Step three: tool call. The rewritten intent reaches for a tool. A shell tool, a file tool, an HTTP client, an MCP server. This is the last moment the attack still lives in "text and JSON" land, and it is where cheap screening earns its keep.
Step four: syscall. The tool does its job, and the job is a kernel request. Running a command is execve. Reading a secret is openat. Opening a socket to a command-and-control host is connect. This is where the abstraction ends and the machine actually does the thing. It is also the point of no return: once execve returns, code is running.
Why the prompt layer cannot hold this line
Prompt-layer defenses (guard prompts, system-message rules, an LLM judge scoring the plan) all live inside the context window. That is precisely the thing step one poisoned. You are asking the compromised component to police itself using instructions that sit next to the attacker's instructions, in the same buffer, weighted by the same attention. It is a guard standing inside the blast radius, reading its orders off the same page the attacker just wrote on.
This is not a claim that prompt defenses are worthless. They catch a lot, cheaply, and they belong in the stack. It is a claim about where they structurally cannot win: they cannot be the last line, because the last line has to be somewhere the attacker's words do not reach. We made the same argument from a different angle in denied is denied: a refusal you can talk your way out of is a negotiation, not a control.
Enforce where the attacker cannot speak
InnerWarden works the far end of the chain, where the text stops mattering and the syscall is about to happen. Two layers, on purpose.
Command screening at step three. Before a proposed command runs, InnerWarden normalizes it, then matches. Normalization is the point: attackers hide intent in quoting, base64, variable splitting, and whitespace tricks, so screening that matches raw strings is trivially bypassed. Normalize first, then decide. This is the cheap early layer, and most days it is all that fires. It is the same posture we describe for the MCP attack surface, where tool outputs are attacker-controlled by default.
The kernel Execution Gate at step four. On Linux, InnerWarden runs an eBPF LSM program on bprm_check_security, the hook the kernel calls while setting up an execve. If an unauthorized binary tries to launch inside the agent's scope, the kernel refuses it before the first instruction of that program runs. There is no context window here to poison, no persona to adopt, no clever framing. The attacker rewrote the agent's intent, but the attacker never gets to talk to the LSM hook. Every decision, allowed or denied, lands in a local audit trail so you can prove what happened after the fact.
Honesty matters here, so: the kernel Execution Gate is Linux-only, because it is a kernel enforcement mechanism. Screening and the guardrail logic run cross-platform, but the deny-before-exec guarantee lives where the LSM lives. If someone tells you they enforce at the kernel on Windows or macOS the same way, ask them which hook.
Defense in depth only counts if the bottom is solid
Keep the polite layers. Keep the guard prompts, keep the screening, keep the LLM judge if you like it. They make the common case cheap and quiet. But layer them on top of something the attacker cannot argue with, because the whole value of depth collapses if the deepest layer is still inside the blast radius. The chain runs injection, intent rewrite, tool call, syscall. Put your hardest control at the end of it, not the start.
We keep a real, unedited recording of the gate refusing a live exec attempt on the proof page: the same binary runs fine on the host and is refused inside the agent's scope. That refusal happens below the layer the injection ever touched. That is the whole idea.