Guardrails are the checks and limits you put around a large language model (LLM) call so that text you did not write cannot make your application say or do something harmful.

Picture a support-ticket assistant for an online store. It reads customer tickets, including attached emails, pulls help-center articles and the customer's order record into its prompt, drafts a reply, and can call three tools: lookup_order, issue_refund, and send_email. Every one of those inputs is text someone else wrote. Guardrails decide what happens when that text tries to steer the assistant: a check on input before the model, a check on output after it, and hard limits on what each tool will do.

In AI engineer interviews this is a standard follow-up once your design has tools or retrieval. The interviewer asks, "What could a malicious ticket or document make your assistant do?" It usually takes three to five minutes, and it goes deeper in forward-deployed roles where you ship assistants into an enterprise's own data. A mid-level answer names prompt injection, adds moderation, and confirms side effects. A senior answer explains why a prompt cannot enforce a rule, moves enforcement into tool code, and checks that the reply is supported by its sources before it goes out.

The organizing idea is defense in depth: no single check is complete, so you stack several that fail in different ways. This tutorial covers the five threats a guarded assistant faces (injection, harmful tool use, jailbreaks, leakage of secrets and personally identifiable information (PII), and invented answers) and the layer that handles each.

Size the stack to what a fooled model could actually do: a read-only feature needs no confirmation step, and small talk ("thanks, that's all") needs no grounding check, while anything that moves money or quotes policy needs every layer. Model safety training belongs to the model provider, and fairness in predictive models belongs to machine learning system design. Both sit outside this tutorial.