Redact a phone number the model echoed in its answer
Block a tool call to delete_customer when the user never asked
Quarantine instructions embedded in a retrieved web page
Detect 'ignore all previous instructions' in the user message
Strip Markdown image tags that exfiltrate data via URL parameters
A safety rail is a checkpoint at a specific boundary of the LLM application. Different problems show up at different boundaries, so you place each check on the rail that owns its boundary.
The input rail runs on the user's message before the model sees it. It catches things the user typed: a secret key pasted into the chat, an injection string like ignore previous instructions, a phone number you do not want sent to the model.
The retrieval rail runs on documents and other external content as they arrive into the context. It catches injections hidden in a retrieved web page or knowledge-base article.
The action rail runs when the model proposes a tool call. It catches the model trying to invoke a dangerous tool the user never asked for, or trying to call a tool with bad arguments.
The output rail runs on the model's response before it leaves your application. It catches PII the model echoed or generated, Markdown image tags that could exfiltrate data, links to disallowed domains.
The rule of thumb: put each check on the rail closest to where the problem can first appear and where you still have the context to do something about it.
Production guardrail stacks separate checks by **boundary**, not by topic. Four rails cover the surface:
- **Input rail.** Fires on the user message before the LLM. Catches injection patterns (ignore all previous instructions), PII paste (an AWS key, an SSN), off-topic content, jailbreak signatures, language-policy violations.
- **Retrieval rail.** Fires when external content arrives into context (RAG documents, web fetches, tool responses). Catches indirect injection embedded in retrieved content, classifies hostile chunks, quarantines or tags them.
- **Action rail.** Fires when the model proposes a tool call. Enforces tool allowlists, argument validation, blast-radius checks, confirmation prompts on irreversible actions. NeMo Guardrails calls this the execution rail.
- **Output rail.** Fires on the model's response before it returns to the user. Redacts PII the model generated or echoed, strips dangerous Markdown (image exfiltration), enforces link-domain allowlists, classifies toxicity.
Mapping each item:
- **AWS key paste** lands on **input**: the data is in the user's message; catch before it leaves the perimeter.
- **Echoed phone number** lands on **output**: it is in the model's generated text; the input rail never saw it.
- **Unwanted delete_customer tool call** lands on **action**: it is a proposed tool invocation, not a piece of text.
- **Instructions in a retrieved web page** land on **retrieval**: the threat is in content that arrived from outside the user.
- **'Ignore all previous instructions' in the user message** lands on **input**: classic direct prompt injection.
- **Markdown image exfiltration** lands on **output**: the model emitted it; the rendering UI would auto-fetch it.
The discipline is to ask, at what boundary does this problem first become visible, and where do I still have the context to act on it.
Quick reference
TL;DR
Safety checks live on four rails, input (before the model), retrieval (when external content arrives), action (when a tool call is proposed), and output (before the response leaves), each rail handles the threats
Picture a kitchen with four doors: the pantry door for ingredients, the back door for deliveries, the stove door for cooking, and the dining-room door for plates going out. A safety inspector watches each one separately. The pantry door checks what the user brings in. The back door checks deliveries from outside. The stove door checks whether the cook is about to do something dangerous. The dining-room door checks whether the plate that is about to leave has anything on it that should not be served. Each problem belongs at the door closest to its cause, because that is where you have the right tools to deal with it.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Single-shot completion with no tools and no retrieval Only input and output rails are meaningful; retrieval and action rails have nothing to guard.
Strictly read-only retrieval over hand-curated corpora Retrieval rail can be replaced by a one-time corpus scan; per-request scanning adds latency without benefit.
Highly latency-sensitive applications (sub-100ms budget) Multiple sequential rails add latency; consider parallel rails or smaller fast classifiers per rail.
Quick scan · 2–4 min
Everything important, quickly.
2 min: name the four rails, walk through one threat per rail, explain why the same topic can land on different rails depending on origin.
Real-world examples
Real products, models, and research that use this idea.
1NVIDIA NeMo Guardrails encodes the four rail types as explicit Colang flow categories, input, output, retrieval, execution.
2AWS Bedrock Guardrails separates content policies (input/output) from sensitive information filters and topic policies, layered with model-side tool-use validation.
3Production teams running Claude Opus 4.7 or GPT-5.5 agents in 2026 typically wire four separate guardrail stages so the on-call can isolate which rail is breaking when an incident fires.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you instrument so that you can answer the question, which rail blocked the most requests this week?
Sign in or go Pro to see the approach for this follow-up.
QWhat is the right rail for a check that needs information from both input and output (e.g. consistency)?
Sign in or go Pro to see the approach for this follow-up.
QHow do multi-agent systems extend the four-rail model?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Putting every check on the input rail because it is the obvious entry point; many threats (model echoing PII, malicious tool calls, injection in retrieved content) cannot be caught there at all.