What Are AI Guardrails and How Do You Add Them?

You’ve built a chatbot, an internal assistant or an AI agent, and it works well in the demo. Then someone asks it to ignore its instructions, paste in a customer’s account number, or approve a refund it has no business approving. That’s the moment most teams realize they need guardrails.

AI guardrails are not a single product or setting. They are a set of controls placed before, after and around a language model so the whole system behaves predictably, even when the model itself doesn’t. This guide explains the 3 layers that matter most, the tools that exist for each, and a practical order for adding them.

What AI guardrails actually are

A large language model is a probabilistic text generator. It follows instructions most of the time, but it can be talked out of them, can make things up and can repeat sensitive data it was shown. Guardrails are the deterministic and semi-deterministic checks you put around that model to catch those failures.

A useful way to think about it: the model is the engine, and guardrails are the brakes, seatbelts and speed limiter. You don’t rely on the engine to stop the car.

Most guardrail setups fall into 3 layers:

1. Input filters check what goes into the model: user prompts, uploaded files and retrieved documents.
2. Output checks inspect what comes out before a user, system or tool sees it.
3. Permission limits control what the AI is allowed to read, change or trigger, no matter what it “decides.”

The OWASP Top 10 for LLM Applications (2025 edition) is a good map of what these layers defend against. Its list includes prompt injection (LLM01), sensitive information disclosure (LLM02), improper output handling (LLM05), excessive agency (LLM06) and system prompt leakage (LLM07).

Layer 1: input filters

Input filters screen content before the model processes it. They catch the most common attacks early and cheaply.

What input filters typically do:

• Prompt injection and jailbreak detection. Flags attempts like “ignore your previous instructions” or role-play tricks designed to bypass rules. Remember that injection can also be indirect: hidden instructions inside a web page, email or PDF the AI reads.
• Topic control. Blocks requests outside the app’s purpose. A billing assistant has no reason to give medical advice.
• PII detection and masking. Finds names, card numbers, Social Security numbers and similar data and masks them before they reach the model or your logs.
• Length and rate limits. Caps prompt size and request volume, which helps with the “unbounded consumption” risk OWASP lists as LLM10.

Input filters reduce risk, but they can’t catch everything. Attackers rephrase, and indirect injection can arrive through any document your system retrieves. That’s why the next 2 layers exist.

Layer 2: output checks

Output checks review the model’s response before it’s shown or acted on. This is where you catch problems the input layer missed and problems the model created on its own.

Common output checks:

• Safety classification. A second model or classifier labels the response as safe or unsafe against categories such as hate, violence or self-harm.
• Sensitive data scanning. Catches account numbers, internal URLs, API keys or system prompt text before they leak.
• Grounding checks. For apps built on retrieval-augmented generation, checks whether the answer is supported by the retrieved sources. This helps reduce AI hallucinations, though it doesn’t remove them.
• Format validation. If the model must return JSON, a date or a product ID, validate it with code. Reject or retry anything that doesn’t match the schema.
• Escaping and sanitizing. Treat model output as untrusted input. Never pass it straight into a database query, shell command or web page without the same sanitizing you’d apply to user input. This is OWASP’s “improper output handling” risk.

Key takeaway: Treat the model like an untrusted user. Check what goes in, check what comes out, and never let its output run anything without validation.

Layer 3: permission limits

Permission limits are the most important layer for AI agents that call tools, browse, send email or change records. Input and output filters are probabilistic. Permissions are hard rules.

OWASP’s “excessive agency” entry describes the core problem: an AI system given more functionality, permissions or autonomy than it needs. If an agent only needs to read orders, don’t give it a database account that can delete them.

Practical permission limits:

• Least privilege. Give each tool and integration the narrowest scope possible: read-only where you can, specific tables or folders rather than everything.
• Per-user authorization. The AI should act with the end user’s permissions, not a super-admin service account. If a user can’t see a record, the AI shouldn’t fetch it for them.
• Human approval for high-impact actions. Refunds, payments, deletions, outbound emails and account changes should require a person to confirm.
• Allow lists over block lists. List the specific tools, domains and actions the AI may use instead of trying to block every bad one.
• Spending and action caps. Limit how many actions, API calls or dollars an agent can spend per session.

If you’re connecting tools through the Model Context Protocol or similar integrations, review each connected tool’s scopes the same way you’d review a new employee’s system access.

Guardrail tools and where they fit

You can build guardrails yourself with code and a second model, or use existing frameworks. Several well-known options exist, and many teams combine them.

A few specifics from the vendor documentation are worth knowing. NVIDIA’s NeMo Guardrails describes input rails that run before the main model (for jailbreak detection, topic control and PII masking) and output rails that can pass, edit or block a response. Amazon’s Bedrock Guardrails documentation lists content filters, denied topics, word filters, sensitive information filters and contextual grounding checks as separate safeguards you configure. Features and pricing change often, so check each provider’s current docs before you design around them.

How to add guardrails to an AI app, step by step

Here’s a practical order that works for most small and mid-size teams.

Step 1: write down what the AI is for

List the tasks the assistant should do, the topics it should refuse and the actions it must never take alone. This becomes the policy your guardrails enforce. If you don’t have one, start with an AI acceptable use policy.

Step 2: map your data and tool access

List every data source, document store and tool the AI can touch. Mark which ones hold personal, financial or confidential data. Cut access to anything the app doesn’t truly need.

Step 3: lock down permissions first

Set least-privilege scopes, per-user authorization and human approval for high-impact actions. This layer protects you even when the filters fail, so do it before tuning anything else.

Step 4: add input filters

Turn on prompt injection detection, topic limits and PII masking. Start with your platform’s built-in options before writing custom rules.

Step 5: add output checks

Add safety classification, sensitive data scanning, schema validation and, for document-based answers, a grounding check. Decide what happens on failure: block, rewrite, retry or route to a person.

Step 6: red-team it

Have colleagues try to break the system. Test direct jailbreaks, hidden instructions in documents, requests for other users’ data and attempts to trigger forbidden actions. Keep the failing prompts as a regression test set.

Step 7: log, monitor and review

Log blocked and flagged events (with sensitive data masked) and review them weekly at first. New attack patterns and false positives both show up here. Note that some providers warn that blocked content can appear in logs, so set up logging with care.

Common mistakes to avoid

• Relying on the system prompt alone. “Never reveal customer data” in the instructions is a request, not a control. OWASP’s system prompt leakage entry warns against putting secrets or security logic in prompts.
• Over-blocking. Filters set too tight frustrate users and push them toward unapproved tools. Measure false positives as carefully as misses.
• Forgetting indirect injection. Any web page, email or file your AI reads can contain hidden instructions.
• Giving agents a shared admin account. This turns every successful injection into a full breach.
• Testing once. Models, prompts and attacks change. Rerun your red-team tests after every model or prompt update.

Guardrails and AI governance

Guardrails are the technical side of a broader risk program. NIST’s AI Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1, published July 2024) is voluntary guidance that lists risks specific to generative AI and suggests actions mapped to the framework’s Govern, Map, Measure and Manage functions. It’s a solid reference when you need to explain your controls to leadership, auditors or customers.

Pair your guardrails with an AI governance checklist and clear rules on what company data can go into AI tools. You’ll find more terms like these in the glossary.

Conclusion

Guardrails turn a clever demo into something you can safely put in front of customers and employees. Start with permission limits, because they hold even when everything else fails. Add input filters and output checks next, then keep testing. No guardrail setup is perfect, but 3 layers working together catch far more than any single control.

Sources

• OWASP Top 10 for LLM Applications 2025 — risk categories including prompt injection, improper output handling, excessive agency and system prompt leakage
• NIST AI 600-1: Generative Artificial Intelligence Profile — voluntary generative AI risk guidance published July 2024
• NVIDIA NeMo Guardrails: rail types — how input and output rails work
• Amazon Bedrock Guardrails documentation — content filters, denied topics, PII filters and grounding checks
• Microsoft Azure AI announcement on Prompt Shields — detection of jailbreak and indirect prompt injection attacks