Order the layers of a defence in depth safety stack from innermost to outermost

Order steps·Medium·4.0 · 0·~1 min·Asked atCoinbase Stability Ai Swiggy

Attempt it

1RLHF / DPO / Constitutional AI preference training
2Pretraining data filtering and curation
3Runtime output guardrails (toxicity, redaction, structure)
4Audit logging and human escalation
5Runtime input guardrails (injection, PII, off topic)
6Behavioural guardrails on tool calls (allowlist, confirmation)
7Supervised fine-tuning on safe demonstrations

**Defence in depth** for an LLM means stacking safety controls at different layers of the request path so that no single failure removes safety. The seven layers, from innermost to outermost: 1. **Pretraining data filtering and curation.** Decisions made about what data the base model sees. Removes the highest-risk content (CSAM, malicious code, private data) from the foundation. 2. **Supervised fine-tuning on safe demonstrations.** Teaches the model basic refusal patterns and helpful honest harmless behaviour using curated demonstrations. 3. **RLHF, DPO, or Constitutional AI preference training.** Aligns the model's preferences using human or model-based preference signals. Shapes the model's prior over outputs on typical inputs. 4. **Runtime input guardrails.** Live code at serving time that inspects every prompt for injection (Llama Prompt Guard, Lakera Guard), PII or secrets, off-topic content, and known jailbreak patterns. 5. **Runtime output guardrails.** Live code that inspects every model response for toxicity (Llama Guard 4, OpenAI Moderation), PII leakage, structural correctness, or citation requirements. 6. **Behavioural guardrails on tool calls.** Code around the orchestrator that enforces a tool allowlist, validates arguments, requires confirmation for irreversible actions, and bounds the number of steps an agent loop can take. 7. **Audit logging and human escalation.** Every rail decision and tool call is recorded immutably; ambiguous or high-risk cases route to a human reviewer. Layers 1-3 live in the weights. Layers 4-7 live in code around the model. The innermost layers reduce the base rate of unsafe behaviour; the outermost layers bound blast radius and produce the audit trail compliance regimes require.

The **defence in depth safety stack** for an LLM has seven layers running from training-time data curation outward to runtime audit logging. The ordering is innermost to outermost in the sense of which layers are baked into the model and which surround it at serving time. **Training-time layers (baked into weights):** 1. **Pretraining data filtering and curation.** Removes high-risk content (CSAM, deliberately malicious examples, leaked private data) from the foundation. This is the deepest layer; everything else operates on the resulting model. Modern frontier teams (Anthropic, OpenAI, Google, Meta) all run multi-stage filtering pipelines. 2. **Supervised fine-tuning on safe demonstrations.** Teaches refusal patterns and helpful behaviour through curated input-output examples. Sets the prior for the alignment phase. 3. **RLHF, DPO, or Constitutional AI preference training.** Aligns the model's preferences using human preference signals (RLHF), direct preference optimisation (DPO), or model-based critique against a constitution (Anthropic's Constitutional AI). Shapes the model's prior on typical inputs. **Runtime layers (code around the model):** 4. **Runtime input guardrails.** Llama Prompt Guard, Lakera Guard, Protect AI Rebuff, secrets-scanners, PII detectors, off-topic gating, jailbreak classifiers. Run before the model sees the prompt. 5. **Runtime output guardrails.** Llama Guard 4, OpenAI Moderation, AWS Bedrock Guardrails content filters, structured-output validators, citation checkers. Run after the model emits a response and before delivery. 6. **Behavioural guardrails on tool calls.** Tool allowlist enforced in orchestrator code, argument validation, confirmation gates on irreversible actions, max-step caps, per-tool rate limits. 7. **Audit logging and human escalation.** Every rail decision and tool call recorded immutably (S3 object lock, equivalent). Ambiguous or high-risk cases routed to human reviewers.

TL;DR

The defence in depth stack runs from training-time data curation through SFT, RLHF, runtime input rails, output rails, behavioural rails on tools, and finally audit logging, innermost (weights) to outermost (logs).

Memory aid

Easy to grasp

Imagine the safety layers of a castle. The deepest layer is the recruitment process for guards, who you let into the castle in the first place. Then comes their training. Then their drills and code of conduct. Out at the gate sits the door guard who checks anyone coming in. Past the door, a second guard checks anything leaving the castle. Around any tool the guards use (keys, weapons), a quartermaster signs items in and out. Finally, a scribe records everything in a ledger. Each layer is independent. If a clever visitor talks past the door guard, the exit guard might still catch them. If both fail, the ledger lets a magistrate review what happened.

Key concepts

Safety and Guardrails Pretraining

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.

Defence in depth is the architectural pattern that makes LLM safety stacks robust to single-point failures. Each individual control, RLHF, input classifier, output classifier, tool allowlist, audit log, fails under some condition. The argument for layering them is that the failure modes are independent: the conditions under which each one fails do not coincide on the same request, so the probability of a coordinated failure is much lower than any single failure.

This deep dive walks through the seven layers in order from innermost (training-time, baked into the weights) to outermost (runtime, surrounding the model), why each layer's failure mode is structurally different from the others, and how production stacks compose them.

The training-time layers (in the weights)

Layer 1: Pretraining data filtering and curation

The innermost layer. Frontier teams (Anthropic, OpenAI, Google DeepMind, Meta) run multi-stage filtering pipelines that remove high-risk content from the pretraining corpus before the base model ever sees it. Categories filtered include CSAM, deliberate malicious code corpora, leaked private data (passwords, credentials), and known synthetic-disinformation farms.

This layer's effectiveness is measured by what does not appear in the model's outputs because it never appeared in the training data. Failure mode: contamination through training-data leakage or filter false negatives.

Layer 2: Supervised fine-tuning on safe demonstrations

After pretraining, the model is fine-tuned on curated input-output examples that demonstrate desired behaviour: helpful answers, appropriate refusals, factual accuracy on common topics. This sets the prior for the alignment phase that follows. Failure mode: distribution shift between SFT demonstrations and real user inputs.

Layer 3: RLHF, DPO, or Constitutional AI

The alignment layer. RLHF uses human preference data to fine-tune the policy. DPO uses the same preference signal more efficiently. Constitutional AI (Anthropic's approach) replaces some human labelling with model-based critique against a written constitution. All three target the same outcome: the model's preferences are shaped toward helpful honest harmless behaviour on typical inputs.

Failure mode: distribution shift to adversarial inputs (jailbreaks, indirect injection) outside the labellers' distribution. This is the failure mode the sleeper-agents and alignment-faking results illustrate, alignment training does not reliably remove deceptive policies and does not generalise to inputs unlike the training data.

The runtime input and output layers (code around the model)

The behavioural and audit layers (the outermost defences)

Why independent failure modes are the whole point

Situations where this technique stops working.

2–4 min · Everything important, quickly.

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

Anthropic Claude Opus 4.7 production deployments combine Constitutional AI alignment with AWS Bedrock Guardrails input/output rails and Bedrock Agents action-group allowlists, all logged to CloudWatch with S3 object-lock retention
OpenAI GPT-5.5 deployments pair the model's RLHF refusals with OpenAI Moderation as input and output rails, plus tool-list allowlists in Assistants v2, plus customer-side audit logs

What an interviewer would ask next. Try answering before peeking at the approach.

QIf you had to drop two layers from the seven for a constrained MVP, which two would you drop and why?

Defensible drops vary by use case. For a chat-only product, behavioural rails (no tools) and pretraining data filtering (you do not control the foundation model) are weakest contributions. For a tool-using agent, never drop behavioural rails, drop pretraining curation (out of your control) and possibly Constitutional AI tier (rely on the provider's RLHF). Always keep input rails, output rails, and audit log.

1 more follow-up 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

Skipping the runtime layers because the training-time alignment looks strong, or skipping the audit layer because the rails seem to work, defence in depth requires independent failure modes.

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

The seven layers of the defence in depth safety stack in order
Which layers are baked into the model weights and which live in code

Primary sources. Browse if you want the original framing.