Guardrails (LLM)

How it works

Guardrails are the controls that constrain what a language model can receive, say, or do, placed around the model rather than inside it. They fall into three layers: input filters (screen incoming text for injection patterns and disallowed content), output filters (scan responses for leaked secrets, PII, or policy violations before they reach a user or a tool), and system-prompt hardening (explicit refusal rules and a clear separation of instructions from data). For agents, the most important guardrails are architectural: least-privilege tool use scopes and human approval on destructive actions.

When it matters

Guardrails matter for any production LLM feature, but their limits matter just as much. Each layer is porous: attackers rephrase and encode around filters, and the system prompt is just more tokens that prompt injection can override. Guardrails are a defense-in-depth strategy, not a single fix, and for tool-calling agents the real control is scoping, not prompting. See Red-Team an LLM and Secure an MCP Server.

Common misconceptions

• "Guardrails stop [prompt injection](/glossary/prompt-injection/)." They reduce volume; they do not close the class. No prompt-level fix is complete.
• "One good filter is enough." Layer input, output, and architecture; assume each is porous.
• "Guardrails and alignment are the same." Alignment is training the model; guardrails are external controls around it.