AI guardrails

What AI guardrails do

Sooner or later a model will produce something you didn't plan for. Guardrails are the code and rules that decide what happens then. They sit outside the model, so they keep working when you change provider.

Take a tool that drafts support replies. An input guardrail strips card numbers from the ticket before the model sees it. An output guardrail blocks any draft that promises a refund the policy doesn't allow.

Types of AI guardrails

Input guardrails screen requests for prompt injection, personal data or topics you don't support. Output guardrails check responses for policy breaches, leaked data or broken formats, such as JSON that won't parse.

Action guardrails matter most for agents. They limit which tools the model can call, cap spend and require a person to approve anything that can't be undone. The OWASP Top 10 for LLM applications names the risk here excessive agency.

Many guardrails aren't models at all. A pattern match for card numbers or a schema check is plain code. It's cheap, fast and easy to test, so use it wherever it does the job.

The layers of AI guardrails

No single check is enough, so guardrails are built in layers. Each one catches what the one before it missed.

• Input checks. Screen what reaches the model: remove personal data, refuse topics you do not support, and flag text that looks like an attempt to override the instructions.
• Output checks. Test what comes back before anyone sees it: the format, the policy rules, and whether a factual claim is supported by the documents the model was given.
• Tool and permission limits. Decide which tools the model may call, with what data, and how much it may spend. A model that cannot send an email cannot be tricked into sending one.
• Human approval. Anything that is hard to undo, such as a payment, a deletion or a message to a customer, waits for a person.
• Monitoring. Log what was blocked and what got through, and review it. This is how you find the failure nobody planned for.

The fourth layer is a design problem as much as an engineering one. Our post on designing the review step before an AI agent acts covers when to ask for approval and what the approval screen must show. For what the user sees when a check blocks something, see error states for AI features.

Guardrails for a first release

You do not need every layer on day one. For a first release, a short list covers most of the risk:

• Check the format. If the model must return structured data, validate it and retry or stop when it does not parse.
• Keep secrets and personal data out. Strip what the model does not need before the request is sent.
• Limit what it can touch. Give the model read access where that is enough, and the smallest set of tools that does the job.
• Put a person before anything irreversible. Payments, deletions and outbound messages wait for approval.
• Log every block and every override. You will need the record to tune the checks.

Add more only when the log shows a failure the existing checks missed. Each new guardrail adds delay and a chance of blocking a good answer, so it should earn its place.

AI guardrails vs evals

Guardrails run on every request in production and act on the spot. Evals run offline against a test set and tell you how often the system gets things right. A guardrail stops a bad answer today. An eval tells you whether this week's prompt change made things worse.

You need both. Guardrail logs feed your evals with real failures, and evals tell you whether a guardrail is blocking good answers. A guardrail that rejects good answers too often is a bug of its own.

For how the offline side works, see AI evaluation.

Where AI guardrails fall short

Guardrails reduce risk. They don't remove it. Prompt injection tops the OWASP list for 2025 and still gets past filters. The safest design limits what a fooled model could actually do.

OpenAI's safety guidance pairs automated checks with adversarial testing and human review of outputs, especially in high-stakes domains. That's a sensible default. Treat guardrails as one layer next to permissions, review steps and monitoring.

The review step has its own entry: human-in-the-loop. It is the layer to rely on when the cost of a mistake is high.

How Gr8r designs AI guardrails

Before writing prompts, we map what could go wrong at each step of the workflow. Then we pick the cheapest check that catches each failure, and we send uncertain cases to a person instead of letting the system guess.

We also design what the user sees when a guardrail fires. A clear message with a way forward works better than a silent failure or a generic error.

For internal workflows this is part of AI workflow automation. For AI inside a product you sell, it is part of product engineering.