Match each safety check to the rail it belongs on

Match pairs·Easy·4.0 · 0·~2 min·Asked atComet Ml Ey Lakera

Attempt it

Drag each answer to line up with its matching prompt

Detect a user pasting an AWS secret key

Output rail

Redact a phone number the model echoed in its answer

Action rail

Block a tool call to delete_customer when the user never asked

Output rail

Quarantine instructions embedded in a retrieved web page

Input rail

Detect 'ignore all previous instructions' in the user message

Retrieval rail

Strip Markdown image tags that exfiltrate data via URL parameters

Input rail

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.

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

Memory aid

Easy to grasp

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.

Key concepts

Safety and guardrails

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Production guardrail stacks are most useful when they are organised by boundary, the moment data crosses into or out of the LLM application, rather than by topic, what the safety check is looking for. The four-rail model (input, retrieval, action, output) is the dominant default because each rail corresponds to a real boundary in the system and to the right point of intervention for the threats that show up there.

This card walks through each rail in turn, then explains the principle behind the separation, and finishes with the operational consequences of getting the placement right or wrong.

The four rails and what each one owns

Input rail. The user has typed a message and your application has received it. Before the message becomes part of an LLM prompt, the input rail inspects it. Common checks include direct prompt-injection detection (the classic ignore all previous instructions), PII paste detection (the user dropped a Social Security number or an AWS access key), off-topic filtering, jailbreak signature matching, and language-policy enforcement. The action is typically refuse with message or redact then continue.

Retrieval rail. Your application has fetched external content into context, a RAG document, a web page, a tool response with substantial text. Before that content joins the prompt, the retrieval rail inspects it. The dominant threat is indirect prompt injection: instructions hidden in retrieved content that the model may follow as if they were authoritative. Common checks include injection classification at chunk granularity, denied-source filtering, and tagging or quarantining suspicious chunks. The action is typically annotate with trust level or drop from context.

Action rail. The model has proposed a tool call. Before the runtime executes the tool, the action rail inspects the call. Common checks include tool allowlisting per agent or session, argument schema validation, blast-radius classification (read-only versus mutating versus destructive), confirmation prompts on irreversible operations, and step-budget enforcement. NeMo Guardrails calls this the execution rail; the substance is the same.

Output rail. The model has produced a response and your application is about to return it to the user. Before the response leaves your perimeter, the output rail inspects it. Common checks include PII redaction on model-generated text, dangerous-Markdown stripping (image and link tags pointing to non-allowlisted domains), toxicity classification, citation presence enforcement, and structured-output schema validation.

Why boundary-based instead of topic-based

Why retrieval and action need to be their own rails

Operational consequences of getting the placement right

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

NVIDIA NeMo Guardrails encodes the four rail types as explicit Colang flow categories, input, output, retrieval, execution.
AWS Bedrock Guardrails separates content policies (input/output) from sensitive information filters and topic policies, layered with model-side tool-use validation.

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?

Emit per-rail counters with category labels; tie blocks to a structured outcome enum the dashboard groups on.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases 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.

60 second bullets to scan on the way to the call.

Names of the four rails and what fires at each boundary
Why PII can land on either input or output depending on origin

Primary sources. Browse if you want the original framing.