Guardrails that hold when the prompt doesn't.
A prompt guardrail is an instruction the model is trusted to follow. A runtime guardrail is a control the model cannot override: it lives outside the agent, screens every action before it executes, and enforces the rules below the process, in the operating system. One poisoned file can rewrite an agent's intentions. It cannot rewrite the kernel.
Three layers, from advice to physics.
InnerWarden implements runtime guardrails as three layers on the machine where your agent works. Each one catches what the layer above misses.
Guard: screen every action before it runs
Every command, file touch, and MCP/tool call your agent proposes is checked against 71 agent threat rules and a risk engine before it executes. Dangerous ones are denied, ambiguous ones go to you, normal work flows untouched.
Enforce: make the dangerous ones impossible
On Linux, enforcement lives in the kernel itself. An unauthorized binary launched by a hijacked agent is refused by the operating system before a single instruction runs. There is no prompt that argues with a denied exec.
Prove: keep evidence of everything it did
A hash-chained, tamper-evident audit trail of every decision stays on your machine. Evidence for you, your customer, or your auditor, and it never leaves your infrastructure.
Why prompt-only guardrails fail
Prompt rules travel inside the model's context, which is exactly the surface an attacker controls through poisoned files, web pages, and tool output. When the context is compromised, the rules go with it. Runtime guardrails sit outside that blast radius: the agent proposes, the guardrail disposes.
Use both. Trust one.
Prompt guardrails still make agents behave better on the happy path, keep them. The mistake is trusting them as your last line. The last line has to be something a compromised agent cannot talk to: a screened action queue and, on Linux, the kernel itself.
The best of what we've written on this.
Runtime guardrails, not prompt guardrails
The thesis: why the safety layer cannot live inside the thing being tricked.
What happens when an AI agent gets hacked
The attack chain from poisoned input to shell, step by step.
Your AI agent needs a bodyguard
How out-of-process guarding works in practice.
Building secure AI agents
Patterns that survive contact with real infrastructure.
Protecting the machine your agent runs on
The host is part of the attack surface. Guard it too.