LLM Guardrails and Safety Patterns Cheat Sheet

Updated 2026-05-18

Next Topic: LLM Observability Cheat Sheet

🧠Study flashcards on this topic87 cards · spaced repetition→

LLM guardrails are runtime controls that validate, filter, and constrain large language model inputs and outputs against security, safety, and compliance policies before responses reach users or trigger downstream actions. Unlike traditional software guardrails that enforce deterministic rules, LLM guardrails must handle the non-deterministic, probabilistic nature of generative AI—detecting prompt injections, toxic content, hallucinations, PII leaks, and jailbreak attempts in natural language. As of 2026, guardrails have shifted from an optional safety layer to production infrastructure essential for enterprise AI applications, driven by regulatory requirements (GDPR, HIPAA, EU AI Act), security imperatives (OWASP LLM Top 10), and business risk (brand damage, compliance violations). The key mental model: guardrails are defense-in-depth layers applied at input validation, model execution, output filtering, and retrieval—not a single checkpoint. Production systems typically combine 3–7 guardrail types in a layered architecture, trading off latency (5–150ms overhead) for risk reduction. Critical insight: no guardrail is perfect—prompt injection remains unsolved in 2026, and adversarial attacks evolve faster than defenses; effective safety requires treating guardrails as risk reduction layers, not hard security boundaries, backed by monitoring, red teaming, and incident response.

What This Cheat Sheet Covers

This topic spans 12 focused tables and 96 indexed concepts, 87 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Guardrail Rail Types and Execution LayersTable 2: Core Detection Techniques and ApproachesTable 3: Prompt Injection and Jailbreak DefensesTable 4: Content Safety and Toxicity ControlsTable 5: PII Detection and Data ProtectionTable 6: Factuality and Hallucination MitigationTable 7: Framework and Platform ImplementationsTable 8: Guardrails for RAG and Retrieval SystemsTable 9: Agent and Tool Execution SafetyTable 10: Observability, Monitoring, and Feedback LoopsTable 11: Bias Detection and Fairness ControlsTable 12: OWASP Top 10 LLM Vulnerabilities and Mitigations

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Guardrail Rail Types and Execution Layers

Guardrails operate at distinct pipeline stages—input validation runs before the LLM sees the request, output filtering runs after generation, retrieval guardrails inspect external documents, and dialogue rails shape conversational flow. Each layer addresses different threat vectors: input rails block malicious prompts, output rails catch toxic or hallucinated responses, retrieval rails prevent vector database poisoning, and dialogue rails enforce conversation boundaries. The layered approach provides defense-in-depth: if prompt injection bypasses input filters, output validation may still catch the malicious result. Production systems typically deploy 3–5 rail types simultaneously—the tradeoff is latency (each layer adds 10–50ms) versus coverage. Most enterprises start with input PII and output toxicity filters (highest ROI), then add prompt injection detection, RAG validation, and topic guardrails based on risk assessment. Architecture matters: running rails in parallel reduces latency but misses cross-layer dependencies; sequential execution catches more threats but increases response time.

Type	Example	Description
Input Guardrails (Pre-LLM)	`if detect_injection(user_msg):` `return "Blocked"`	Run before the LLM sees the request — validate input syntax, detect prompt injections, redact PII, check topic boundaries, enforce content policies, and sanitize user queries to prevent manipulation or data leakage before inference.
Output Guardrails (Post-LLM)	`if toxic_score > 0.8:` `response = fallback_msg`	Run after generation completes — filter toxic language, detect hallucinations, verify factual grounding, redact sensitive data, enforce structured schemas, and validate citation accuracy before the response reaches users or downstream systems.
Retrieval Guardrails (RAG-specific)	`if relevance_score < 0.5:` `reject_document()`	Validate external documents before context injection — check retrieval relevance, detect corpus poisoning, verify source trustworthiness, enforce context length limits, and prevent indirect prompt injection via RAG document manipulation.
Dialogue Guardrails (Conversational)	`if off_topic(user_turn):` `redirect_to_scope()`	Shape multi-turn conversation flow — enforce topic boundaries, manage state transitions, detect goal hijacking, limit conversation depth, prevent jailbreaks via multi-step exploits, and ensure the agent stays within its intended role across turns.
Tool/Action Guardrails	`if action == "delete_db":` `require_approval()`	Control agent tool access and execution — enforce least-privilege permissions, validate function arguments, detect unauthorized API calls, sandbox code execution, rate-limit tool invocations, and prevent agents from performing destructive actions without human oversight.
Runtime Guardrails (Real-time)	`if latency > 5s:` `timeout_request()`	Monitor system behavior during execution — detect infinite loops, enforce cost limits, track token budgets, measure latency spikes, identify anomalous request patterns, and trigger circuit breakers to prevent cascading failures or runaway costs.

Table 2: Core Detection Techniques and Approaches

Detection techniques combine rule-based patterns, machine learning classifiers, embedding similarity, and LLM-based judges to identify safety violations. Each approach has distinct speed/accuracy tradeoffs: regex is fast (sub-ms) but brittle; semantic similarity catches paraphrased attacks but requires embeddings (20–50ms); ML classifiers balance speed and accuracy (5–30ms) but need training data; LLM-as-judge is most flexible but slowest (200–800ms) and least deterministic. Production systems typically cascade techniques—start with lightweight pattern matching to catch obvious violations, escalate to semantic classifiers for ambiguous cases, and reserve LLM judges for nuanced policy decisions. The frontier as of 2026: ensemble voting (combining 3–5 detection methods) achieves 85–95% accuracy with 10–20% false positive rates—better than any single technique. Critical insight: detection is necessary but insufficient—attackers constantly discover new bypass techniques; effective safety requires continuous red teaming, monitoring detection gaps, and updating models quarterly.

Technique	Example	Description
Pattern Matching (Regex)	`re.search(r"Ignore.*instructions", text)`	• Lightweight rule-based filtering using regular expressions to detect known attack phrases, PII patterns (SSN, credit cards), forbidden keywords, or code injection attempts • fast (sub-millisecond) but easily bypassed with paraphrasing or obfuscation.

The rest of this section is part of the full cheat sheet

Table 3: Prompt Injection and Jailbreak Defenses

Prompt injection remains the #1 LLM vulnerability in OWASP's 2026 ranking—no perfect defense exists, but layered mitigations reduce risk. Direct injection attempts override system instructions via user input; indirect injection embeds malicious instructions in external data (web pages, emails, RAG documents) that the LLM retrieves. Jailbreaks use creativity, personas, encoding tricks, or multi-turn manipulation to bypass safety alignment. Defense strategies combine input sanitization, context isolation, instruction hierarchy enforcement, and output validation. The fundamental challenge: LLMs lack syntactic boundaries between instructions and data—they process "system prompt" and "user input" identically. As of 2026, best practices involve privileged prompt sections (marked trusted vs untrusted), LLM-based injection detectors trained on adversarial datasets, and architectural separation (different agents for different trust contexts). Detection accuracy: specialized models like Lakera Guard and Azure Prompt Shields achieve 90–98% detection on known attacks, but novel techniques bypass them weekly—continuous red teaming is essential.

Pattern	Example	Description
Input Sanitization	`sanitize(user_input).strip_instructions()`	• Pre-process user inputs to remove known attack patterns, special tokens, or instruction-like phrasing before passing to the LLM • quick first-pass filter but easily bypassed with paraphrasing or novel syntax • use as first layer, not sole defense.

The rest of this section is part of the full cheat sheet

Table 4: Content Safety and Toxicity Controls

Content safety guardrails filter toxic language, hate speech, sexually explicit content, violence, self-harm instructions, and other harmful outputs prohibited by platform policies or regulations. Unlike deterministic filters, toxicity is contextual—"kill the process" in a technical discussion is benign, but "kill the person" is harmful. Modern toxicity detectors use fine-tuned classifiers (Meta's Llama Guard, Perspective API, Azure Content Safety) trained on labeled datasets covering multiple harm categories: hate speech, harassment, sexual content, violence, self-harm, profanity, and child safety. Detection is probabilistic—models return risk scores per category (0.0–1.0), and thresholds determine blocking. As of 2026, ensemble approaches combining multiple classifiers reduce false positives (blocking benign content) while maintaining high recall (catching actual violations). Key challenge: adversarial users craft prompts that generate harmful content without triggering filters—e.g., requesting toxic content in a fictional context or via indirect phrasing. Defense requires both input and output validation plus continuous adversarial testing.

Control	Example	Description
Toxicity Classification (ML-based)	`toxic_score = classifier(text)` `if toxic_score > 0.7: block()`	• Use fine-tuned ML models to score text across harm categories (hate, violence, sexual, self-harm) • returns per-category probabilities allowing granular thresholds • Meta Llama Guard, Perspective API, Azure Content Safety are production-grade detectors.

The rest of this section is part of the full cheat sheet

Table 1: Guardrail Rail Types and Execution Layers

Type	Example	Description
Input Guardrails (Pre-LLM)	`if detect_injection(user_msg):` `return "Blocked"`	Run before the LLM sees the request — validate input syntax, detect prompt injections, redact PII, check topic boundaries, enforce content policies, and sanitize user queries to prevent manipulation or data leakage before inference.
Output Guardrails (Post-LLM)	`if toxic_score > 0.8:` `response = fallback_msg`	Run after generation completes — filter toxic language, detect hallucinations, verify factual grounding, redact sensitive data, enforce structured schemas, and validate citation accuracy before the response reaches users or downstream systems.
Retrieval Guardrails (RAG-specific)	`if relevance_score < 0.5:` `reject_document()`	Validate external documents before context injection — check retrieval relevance, detect corpus poisoning, verify source trustworthiness, enforce context length limits, and prevent indirect prompt injection via RAG document manipulation.
Dialogue Guardrails (Conversational)	`if off_topic(user_turn):` `redirect_to_scope()`	Shape multi-turn conversation flow — enforce topic boundaries, manage state transitions, detect goal hijacking, limit conversation depth, prevent jailbreaks via multi-step exploits, and ensure the agent stays within its intended role across turns.
Tool/Action Guardrails	`if action == "delete_db":` `require_approval()`	Control agent tool access and execution — enforce least-privilege permissions, validate function arguments, detect unauthorized API calls, sandbox code execution, rate-limit tool invocations, and prevent agents from performing destructive actions without human oversight.
Runtime Guardrails (Real-time)	`if latency > 5s:` `timeout_request()`	Monitor system behavior during execution — detect infinite loops, enforce cost limits, track token budgets, measure latency spikes, identify anomalous request patterns, and trigger circuit breakers to prevent cascading failures or runaway costs.

Table 2: Core Detection Techniques and Approaches

Technique	Example	Description
Pattern Matching (Regex)	`re.search(r"Ignore.*instructions", text)`	• Lightweight rule-based filtering using regular expressions to detect known attack phrases, PII patterns (SSN, credit cards), forbidden keywords, or code injection attempts • fast (sub-millisecond) but easily bypassed with paraphrasing or obfuscation.

Table 3: Prompt Injection and Jailbreak Defenses

Pattern	Example	Description
Input Sanitization	`sanitize(user_input).strip_instructions()`	• Pre-process user inputs to remove known attack patterns, special tokens, or instruction-like phrasing before passing to the LLM • quick first-pass filter but easily bypassed with paraphrasing or novel syntax • use as first layer, not sole defense.

Table 4: Content Safety and Toxicity Controls

Control	Example	Description
Toxicity Classification (ML-based)	`toxic_score = classifier(text)` `if toxic_score > 0.7: block()`	• Use fine-tuned ML models to score text across harm categories (hate, violence, sexual, self-harm) • returns per-category probabilities allowing granular thresholds • Meta Llama Guard, Perspective API, Azure Content Safety are production-grade detectors.