Guardrails — Module 13.1

How This Lesson Fits the Module & Volume

Prompts steer models; they do not fully control them. Guardrails are the product and safety layer around prompting—input filters, output validators, policy engines, and human escalation—that backstop system prompts, structured outputs, and chains.

Module 13.1 closes with measuring whether prompts (and guardrails) actually work: prompt evaluation.

Learning Objectives

By the end of this lesson, students should be able to:

Define prompt-time guardrails vs. model-only instructions.
Apply input, output, and tool-level controls.
Detect common jailbreak / injection patterns in user content.
Combine allowlists, schemas, and secondary classifiers.
Design fail-closed behavior for high-risk actions.
Log refusals and violations for evaluation loops.

Definition

Guardrails are deterministic or model-assisted controls placed before, during, or after LLM calls that enforce safety, privacy, format, and authorization policies—independent of hoping the base model always obeys natural-language rules.

Defense in Depth

Ingress

Filter / sanitize inputs.

Model

System policy + tools.

Egress

Validate / redact outputs.

Action

Auth before side effects.

Layer	Example	Failure mode if missing
Input	PII scrub, length caps, injection heuristics	Poisoned context
Prompt policy	System refusals, grounded-only rules	Soft, bypassable guidance
Output	Schema check, toxicity/PII classifiers	Bad content reaches users
Tool/API	Allowlisted functions, human approval	Unauthorized side effects

Soft (in-prompt)

“Never reveal secrets”
Role boundaries
Cheap but brittle

Hard (in code)

Regex / classifiers
JSON Schema reject
RBAC on tools

Process

Human review queues
Rate limits
Incident playbooks

Practical Guardrail Wrapper

import json, re

INJECTION_HINTS = re.compile(
    r"(ignore (all|previous) instructions|system prompt|do not follow)",
    re.I,
)

def guard_and_call(user_text: str, call_llm):
    if len(user_text) > 8_000:
        return {"blocked": True, "reason": "input_too_long"}
    if INJECTION_HINTS.search(user_text):
        # soft signal: quarantine or escalate; do not trust as instructions
        user_text = f"\n{user_text}\n"

    raw = call_llm([
        {"role": "system", "content": SYSTEM_POLICY},
        {"role": "user", "content": user_text},
    ])

    try:
        data = json.loads(raw)
    except json.JSONDecodeError:
        return {"blocked": True, "reason": "invalid_json"}

    if data.get("action") == "refund" and data.get("amount", 0) > 50:
        return {"blocked": True, "reason": "needs_human_approval", "draft": data}

    # PII / toxicity classifiers would run here before return
    return {"blocked": False, "data": data}

Strengths

Enforces policy when models slip
Protects tools and data planes
Produces auditable block reasons

Tradeoffs

False positives frustrate users
Heuristics need maintenance
Overblocking can hide model bugs

Common Misconception

“A strong system prompt is enough guardrailing.” System text is necessary but insufficient. High-impact actions need allowlists, schema validation, and authorization checks in application code. Measure both helpfulness and safety with prompt evaluation.

Knowledge Check

Short Answer: What are guardrails? Answer: Controls around LLM calls that enforce safety, privacy, format, and auth policies.
True/False: System prompts alone are a hard security boundary. Answer: False.
Multiple Choice: Egress checks run: (a) on model outputs before delivery, (b) only on GPUs, (c) inside embedding tables. Answer: (a).
Short Answer: Name one ingress control. Answer: Length caps, PII scrubbing, or injection heuristics (any valid).
True/False: Tool calls should be allowlisted and authorized. Answer: True.
Multiple Choice: Fail-closed means: (a) block when unsure on high-risk actions, (b) always approve refunds, (c) delete logs. Answer: (a).
Short Answer: Why log block reasons? Answer: Auditing, tuning false positives, and evaluation.
Short Answer: How do schemas act as guardrails? Answer: They reject malformed or out-of-policy structured outputs.
Multiple Choice: Labeling user text as untrusted helps against: (a) prompt injection, (b) softmax saturation, (c) batch norm drift. Answer: (a).
True/False: Guardrails should be tested alongside prompts in eval suites. Answer: True.

Key Takeaways

Guardrails enforce policy outside soft prompt text.
Use ingress, egress, and tool authorization together.
Fail closed on risky actions; log everything.
Next: Prompt Evaluation.

Trainer’s Guide

Hands-on: Build a mini wrapper that blocks invalid JSON and flags injection phrases; red-team it with 10 attacks.

Discussion: Where should human-in-the-loop sit in a refund or medical advice flow?

Recap: Guardrails turn prompt policy into enforceable product controls. Finish the module with Prompt Evaluation.