Llm guardrails

LLM guardrails

Guardrails assume the model will sometimes be wrong, manipulated, or both, and make the system safe anyway. The architecture is defense in depth: filter what enters, validate what leaves, privilege-limit what the model can touch, and route the irreducible risk to humans.

Method

1. Treat all model-visible content as untrusted. User messages, retrieved documents, tool results, and web content can all carry injected instructions ("ignore your instructions and..."): the defense is structural, not politeness: delimit data from instructions in the prompt, strip/flag instruction-shaped content in retrieved data, and never let model output directly trigger privileged actions (see tool-use-design's boundary: server-side authz decides, the model only requests).
2. Bound the blast radius by construction. The agent's credentials scope to the task (see least-privilege, iam-design); destructive tools require confirmation or policy approval (see automation-guardrails); spending, sending, and deleting have hard caps and rate limits independent of model judgment (see rate-limiting). Assume injection succeeds and ask what the attacker then controls: that inventory is your real exposure (see threat-modeling).
3. Filter inputs proportionate to the surface. Moderation classifiers for abuse categories on public surfaces; jailbreak-pattern detection where stakes justify it; size/rate limits always (see request-validation): tuned against false positives, because over-blocking legitimate users is its own failure (measure both directions: see llm-eval-design's should-not-refuse sets).
4. Validate outputs before they act or ship. Structured outputs against schema (see structured-output), citations against sources (groundedness checks for RAG: see rag-pipeline), policy checks on generated content (PII leakage: see pii-handling; unsafe categories), and plausibility bounds on extracted values: with a defined action per failure (regenerate, redact, escalate: see api-error-responses' decision discipline).
5. Design the human escalation path. Confidence thresholds, sensitive-topic triggers, user requests for a human, and repeated failure loops route to people: with context handed over (conversation summary, what was attempted: see agent-handoff-protocol's contract, human edition) and honest UI about the transition (see conversation-design). Systems without an escape hatch convert edge cases into incidents.
6. Red-team and monitor continuously. Adversarial testing before launch and on a cadence (injection attempts through every input channel including documents and tool results: see penetration-test-prep's mindset); production monitoring for guardrail trigger rates, novel attack patterns, and refusal drift (see llm-observability, security-incident-response for when one lands); every confirmed bypass becomes an eval case (see llm-eval-design's regression loop).

Boundaries

• Guardrails reduce and contain risk; they do not produce a safe-by-construction system: capability decisions (what the system can do at all) dominate any filter stack, and some deployments are wrong at the capability level.
• Over-restriction is a real cost: measured false-refusal rates and user friction belong in the same review as bypass rates (see product-metrics' guardrail symmetry).
• Compliance regimes (privacy, sector rules) set floors that engineering judgment cannot waive; involve the owning functions early (see pii-handling, data-retention).