How to write guardrails for LLM security

Short answer: guardrails are checks around a language model that stop unsafe inputs and outputs and limit what the model can do. Use layers: validate and screen inputs, keep untrusted text (documents, web pages, tool results) separate from instructions, give tools the least privilege, require human approval for risky actions, check and redact outputs, and log everything. No single filter stops prompt injection, so design the system so that a fooled model cannot do much damage.

The threats to plan for

The OWASP Top 10 for LLM Applications is the standard checklist. The ones that hurt most in practice:

• Prompt injection: instructions hidden in user input or in retrieved content ("ignore previous instructions...").
• Sensitive data disclosure: the model repeats personal data, secrets or another user's information.
• Excessive agency: an agent with broad tools takes an action nobody intended.
• Improper output handling: model output is run as code, SQL or HTML without checks.

Layer 1: input checks

• Limit length and file types; reject what your app does not need.
• Screen for known injection patterns and for off-topic requests (a pattern check, a small classifier or a moderation model). See a simple detector on the prompt injection glossary page, and remember that pattern lists catch only crude attacks.
• Mark untrusted content clearly in the prompt (delimiters, a separate message) and tell the model it is data, not instructions.

Layer 2: limit what the model can do

• Least privilege: read-only tools by default; separate tools for reading and writing.
• Allow-lists: which tables, folders, recipients or URLs a tool may touch.
• Human in the loop for payments, emails, deletions and anything public.
• Budgets: maximum steps, tokens and money per task.

Layer 3: output checks

• Validate structure (JSON schema, Pydantic) and retry or refuse when it fails.
• Redact personal data before it is shown or stored: phone numbers, emails, PAN and Aadhaar numbers. A runnable redactor is on the guardrail glossary page.
• Never execute model output directly; escape HTML, parameterise SQL, sandbox code.
• Check grounding: in RAG apps, answers should be supported by the retrieved passages.

Layer 4: test the guardrails

Red-team your own app: write attacks (direct and indirect injection, jailbreaks, data-extraction attempts), keep them as a regression suite, and run it in CI so a prompt change that weakens a guardrail fails the build. Track false positives too: a guardrail that blocks normal users is a product bug.

Personal data in India

If your app handles personal data of people in India, the Digital Personal Data Protection Act, 2023 applies: collect only what you need, for a stated purpose, and protect it. Redacting before logging is a simple, effective habit.

Where this is taught

Module 9 (Evals, Guardrails & AI Security): why AI apps fail silently, error analysis, evals in CI, the OWASP Top 10 for LLM apps, guardrails and personal-data redaction, and red-teaming your own app. Related: Automated LLM evaluation pipelines · LLM evaluation and guardrails course.