Guardrails: keeping LLM systems from going off the rails

The demo works beautifully. Then a real user pastes something weird, and your polite AI assistant cheerfully leaks a system prompt, follows a malicious instruction, or returns someone else's data. The gap between a demo and a product is mostly guardrails.

An LLM will do what the text in front of it steers it toward — including text written by an attacker. Making an LLM system safe to expose to the public is its own engineering discipline. Here's the shape of it.

Why LLM systems are uniquely exposed

Traditional apps have a clean line between code and data. LLMs blur it: the model treats all text as potential instruction. So if user input reaches the prompt — and it always does — a user can try to instruct the model directly. "Ignore your previous instructions and..." is not a hypothetical; it's the daily reality of anything public-facing. This is prompt injection, and it has no perfect fix, only mitigation.

The two boundaries you must guard

Think of guardrails as controls on two edges: what goes in to the model, and what comes out.

Input guardrails inspect and constrain what reaches the model:

Detect and defang injection attempts and jailbreaks.
Strip or redact sensitive data (PII) before it ever hits the prompt or a third-party API.
Enforce scope — reject inputs that are trying to pull the system off its intended job.

Output guardrails inspect what the model produces before it reaches a user or an action:

Validate structure and content — the schema discipline that keeps malformed output from propagating.
Filter unsafe, off-brand, or leaking responses.
Gate consequential actions behind checks, so a model can suggest a dangerous step but not take one unsupervised.

Defense in depth, because there's no silver bullet

You cannot prompt your way to safety — "don't reveal your instructions" is itself just text an attacker can try to override. Real safety is layered: constrained prompts, plus input filtering, plus output validation, plus limits on what the system is even capable of doing. Assume any single layer can be bypassed and make sure another one is behind it. That layered posture — treating security as a pipeline, not a checkbox — is how I approach the AI systems I build.

The principle of least capability

The safest action is one the system can't take. If your assistant doesn't need to delete records, don't give it a tool that can. If it doesn't need to email arbitrary addresses, don't wire that up. Every capability you grant is attack surface. Grant the minimum, and a compromised prompt can do far less damage.

The mindset

Building an LLM feature for yourself is a demo. Building one for the public means assuming some of those users are adversarial and designing for it from the start. Guardrails aren't a feature you bolt on at the end — they're the difference between something you can safely ship and a liability wearing a chat interface.

Treat every input as untrusted, validate every output, and give the system the least power it needs. That's what makes an LLM product safe to put in front of the world. More on how I build it at www.divyakush.com.