AI guardrails are technical controls that check the inputs, outputs and actions of LLM applications and AI agents against defined policies. They detect problems such as prompt injection, leaked personal data, toxic or off-topic content and unsafe tool calls, and then block, redact, correct or escalate the request before harm occurs.
What are AI guardrails?
AI guardrails are the controls that sit around a large language model and keep its behavior within acceptable limits. A model alone cannot guarantee that it will refuse a manipulated instruction, never reveal personal data or always stay on topic. Guardrails add checks before and after the model call, and around any action an agent takes, so that the application enforces policies even when the model does not.
The term covers a broad range: simple rules such as a regular expression for credit card numbers, classifier models that score toxicity, a second LLM that judges an answer, schema validation for structured output, and permission systems that decide which tools an agent may call.
Guardrails have become more important as LLM applications moved from answering questions to taking actions. A chatbot that gives a wrong answer is a quality problem; an agent that sends an email, changes a database record or runs code based on a manipulated instruction is a security incident. The more autonomy and access an application has, the more its guardrails need to be enforced in code rather than in the prompt, and the more they need to be visible in monitoring.
Types of guardrails
| Type | Checks | Typical action |
|---|---|---|
| Input guardrails | User prompts and retrieved content for injection attempts, banned topics, PII | Block, redact, ask for clarification |
| Output guardrails | Responses for PII leaks, toxicity, unsupported claims, format errors | Redact, regenerate, fall back to a safe answer |
| Action guardrails | Tool calls of agents against allowlists, scopes and limits | Deny, require human approval |
| Operational guardrails | Token budgets, request rates, loop counts | Throttle, stop the run |
Output checks for factual grounding are closely related to detecting hallucinations, and input checks are the first line of defense against prompt injection.
How guardrails work in a request
- The application receives a prompt and runs input checks. A violation stops the request or removes the problematic part.
- The model is called with a system prompt that also states the policy, but the policy is not left to the prompt alone.
- If the model wants to call a tool, an action guardrail verifies the tool, its arguments and the caller's permissions.
- The response passes output checks before it is shown or stored.
- Every decision is recorded with the rule that fired, so it can be reviewed later.
The order matters for cost and latency. Cheap deterministic checks such as pattern matching and schema validation should run first, classifier models next, and expensive LLM-based judges only where they add value. Some output checks can run on the streamed response in parallel, but anything that must block a leak has to complete before the text reaches the user.
Example: a support assistant
An illustrative policy for a customer support assistant: input checks flag instructions such as "ignore your previous rules" in user messages and in retrieved help-center pages. Output checks mask IBANs and email addresses that are not the customer's own. The assistant may call get_order freely, but issue_refund requires approval by an agent above an example threshold of 50 euros. A token budget per conversation stops runaway loops. Each blocked or modified response goes to a review queue.
Best practices
- Layer your defenses. No single check is reliable; combine rules, classifiers and permission limits.
- Enforce permissions outside the model. An agent should not be able to do anything its credentials do not allow, regardless of what it is told.
- Measure false positives. Guardrails that block legitimate requests hurt users; track block rates per rule and review samples.
- Watch latency. Each check, especially an LLM-based judge, adds time to the response.
- Test guardrails with evals and red-team datasets before every prompt or model change.
Monitoring guardrails in production
Guardrails are only useful if you know when and why they fire. Record each check as a span or event in the trace of the request, with the rule name, the result and the latency. Useful signals are violation rate per rule, model and tenant, sudden changes in the rate after a release, and the share of requests that end in a fallback answer. A spike in injection detections, for example, can indicate an attack or a new document source with problematic content.
How Obseria helps
Obseria's AI observability scores responses for hallucinations, toxicity, PII leaks and prompt injection and routes violations to a review queue. Guardrail results appear in the same trace as the LLM and tool calls. For background, see what is LLM observability.
