What are LLM guardrails? A practical guide to implementing them with evals
Without guardrails, an LLM application can expose sensitive data, return unsafe content, or follow malicious instructions. Static filters can catch known patterns, but they do not reveal missed violations or show how accuracy changes as prompts, models, and production traffic evolve.
LLM guardrails evaluate model inputs and outputs against defined policies, then block, redact, flag, or trigger another action when a violation is detected. An evaluation-based setup combines custom scorers with online scoring, thresholds, and automations. The same policy can screen changes before deployment and monitor production afterward.
This guide explains how to build that evaluation loop and compares six guardrail tools. Braintrust is a great option for teams that want one evaluation layer across experiments and live traffic, with recorded scores and a direct path for adding production failures to regression datasets. Start evaluating your guardrails with Braintrust →
What are LLM guardrails?
LLM guardrails can inspect prompts and responses, applying a defined action when a policy score crosses its threshold.
LLM guardrails are controls that evaluate what enters and leaves a large language model, then respond when the content violates a defined rule. Depending on the policy, a guardrail may block a toxic response, redact personal information from a prompt, or flag medical advice that the application is not permitted to provide. These rules usually reflect the product's content policies, compliance requirements, and known failure modes.
Two related controls are often treated as complete guardrail strategies, although neither provides application-specific measurement on its own.
Model-provider alignment: OpenAI, Anthropic, Google, and other providers train safety behavior into their models and apply policies at the model level. These controls can reduce harmful outputs, but they follow the provider's policies and release cycle. Product-specific requirements, such as prohibiting legal advice, competitor claims, or unapproved health statements, still need to be defined and evaluated by the application team.
Static content filters: These filters inspect an input or output at the request boundary and allow, block, redact, or flag it according to fixed rules. They support immediate enforcement, but their results do not establish how many violations passed undetected or whether accuracy has changed as production traffic evolves.
For this guide, an LLM guardrail consists of a written policy, a scoring method, a pass-or-fail threshold, and an action for violations. This structure makes each policy measurable and provides the data needed to evaluate its performance over time.
Why static filters fail in production
Static filters can block, redact, or flag content at request time, but enforcement alone does not show whether those decisions are accurate. Their largest limitations appear after deployment and can remain hidden without continuous evaluation.
The false-negative rate remains unknown: Blocked content is visible, so teams can review false positives and adjust the rules. Violations the filter misses continue through the application and may never be identified. Independently scoring samples of the same traffic lets teams estimate how many violations are slipping through.
Accuracy changes with production conditions: User behavior evolves, new audiences introduce unfamiliar prompts, model providers release updates, and engineering teams revise system instructions. A filter tuned against earlier traffic may perform differently after any of these changes.
Block counts provide limited audit evidence: The number of interventions shows how often a filter acted, but it does not establish whether those interventions were correct. A stronger compliance record includes scored production samples, reviewed decisions, and accuracy results across model and prompt versions. For more on building that record, see the guide to audit-ready LLM logging.
Failures may never reach pre-deployment tests: When a missed violation is not captured and added to an evaluation dataset, future releases are not tested against that failure. The same issue can then return after a prompt edit or model change.
A static filter enforces a policy at the request boundary. Continuous evaluation measures its decisions over time, surfaces missed violations, and converts production failures into regression test cases.
Guardrails as an evaluation workflow
Teams that already run evaluations before deployment have most of the components needed to build measurable guardrails. The workflow connects policy definition, production scoring, and a response when violations occur.
Custom scorers define the policy. A custom scorer evaluates an input, output, or complete trace against criteria you define. Deterministic requirements, such as banned terms, required disclaimers, or account-number patterns, can use code-based scorers. Subjective policies covering toxicity, tone, or unsafe advice can use LLM-as-a-judge scorers. Braintrust's guide to writing a custom scorer covers both approaches.
Online evaluation applies the policy to production traffic. Online evaluation runs scorers asynchronously as production traces arrive. Teams can control the sampling rate and evaluate an individual response, a tool call, or the complete trace. Each result is stored with the underlying trace, creating a scored history of policy performance.
Alerts and automations respond to violations. Braintrust automations and alerts can filter production logs by score, metadata, and other trace data. Matching violations can be sent to Slack or a webhook connected to a review queue, paging system, or application logic. Because online scoring runs asynchronously, policies that must block a response before it reaches the user still require an inline check.
The same scorer can run across experiments and production. Before deployment, it evaluates proposed changes against a controlled dataset. After deployment, it scores live traces and surfaces new violations. Those production failures can then be added to the dataset, ensuring future prompt and model changes are tested against cases the application has encountered.
How to build a guardrail pipeline in five steps
The pipeline below assumes your application already sends production traces to Braintrust. Once logging is in place, you can define a policy, evaluate it on live traffic, and configure a response from the same project.
Step 1. Write the policy as a scorer
Translate the written policy into criteria the scorer can evaluate. A requirement that responses contain no personal data may use pattern matching for email addresses, phone numbers, and account identifiers. A policy requiring respectful responses under provocation may use an LLM-as-a-judge scorer with clear grading instructions and labeled examples.
Test the scorer against known passes and violations before applying it to production. Review incorrect judgments and refine the criteria until the results are consistent with your policy.
Step 2. Configure online scoring
Create an online scoring rule that applies the scorer to production traces. Low-cost code-based checks can run across all matching traffic, while LLM judges can use sampling rates based on cost and policy severity.
Set the scorer scope to an individual span for response-level checks or the complete trace when the decision depends on the full conversation or sequence of tool calls.
Step 3. Define thresholds and severity levels
Choose the score that separates a pass from a violation, then assign a severity level to each policy. A detected personal data leak may require an immediate notification, while a borderline tone violation may go into a scheduled review queue.
Documenting these responses keeps low-risk findings from generating the same level of urgency as critical safety or compliance failures.
Step 4. Configure the alert or automation
Create an alert that identifies violations using the scorer result and relevant trace metadata. Review-level issues can go to Slack, while high-severity findings can be sent through a webhook to a paging or ticketing system.
A webhook can also connect to application logic that quarantines a session, disables an affected feature, or activates a safer fallback, though blocking a response before delivery still belongs to an inline check in the request path.
Step 5. Add confirmed violations to the dataset
Review each detected violation and add confirmed failures to the evaluation dataset with the correct expected behavior. Those production failures can then join the dataset, so every future prompt or model change is checked against the exact failures the application has already produced.
Coverage compounds with each review cycle, and the dataset gradually shifts from hand-written examples toward the failure modes your real traffic produces.
What LLM guardrails should cover
Most applications need multiple guardrails, with separate scoring logic and thresholds for each policy. Use the categories below to define the initial coverage for your application.
| Category | What the scorer checks | Scorer approach | Go deeper |
|---|---|---|---|
| Content policy and toxicity | Hostile, hateful, abusive, or otherwise prohibited language | LLM-as-a-judge scoring against the application's written content policy | Prebuilt moderation scorers |
| Safety | Harmful instructions, dangerous advice, self-harm content, or other defined safety risks | LLM-as-a-judge scoring with separate criteria and severity levels for each type of harm | LLM-as-a-judge scoring |
| Prompt injection | Inputs that attempt to override system instructions, expose secrets, or manipulate connected tools | Classifier or code-based scorer applied to model inputs | Prompt injection detector cookbook |
| PII and compliance | Personal data in prompts or responses, prohibited claims, and missing disclosures | Code-based checks for structured patterns and LLM-as-a-judge scoring for contextual requirements | AI governance platforms |
Create separate scorers for each category so they can use different thresholds, sampling rates, and response procedures. Begin with the policy linked to the highest potential impact, calibrate it against representative traffic, and expand coverage once its results are reliable.
LLM guardrails tools compared
Use the comparison below to evaluate how six tools define, enforce, and measure LLM guardrails.
| Tool | Type and pricing model | Core strength | What it checks | How it enforces | Measurement and feedback loop |
|---|---|---|---|---|---|
| Braintrust | Evaluation and observability platform. The free Starter plan includes 1 GB of processed data and 10,000 custom scores per month, with paid usage and plans available. | The same scorer can run in pre-deployment experiments and online evaluation, connecting production monitoring directly to regression testing. | Any policy expressed through custom code, an LLM-as-a-judge, or a prebuilt scorer. Scorers can evaluate individual spans or complete traces. | Production scoring runs asynchronously and can trigger Slack alerts or webhooks. Experiment results can support CI checks before deployment. Braintrust does not provide native inline blocking. | Complete evaluation loop. Scores remain attached to experiments and production traces, and confirmed failures can be added to versioned datasets for future evaluations. |
| NVIDIA NeMo Guardrails | Apache-2.0 open-source Python toolkit. Teams manage their own infrastructure and model costs. | Programmable control across input, dialog, retrieval, execution, and output rails. Colang supports multi-turn conversation rules and tool behavior. | Inputs, conversation flow, retrieved context, tool execution, and model outputs. Exact coverage depends on the configured rails and underlying models. | Runs in the request path and can block, modify, redirect, or control conversation and tool execution. | Logs, metrics, OpenTelemetry tracing, and rail-specific evaluation tools are available. Cross-release experiment tracking and an automated trace-to-dataset loop require additional tooling. |
| Guardrails AI | Apache-2.0 Python framework. Guardrails Pro provides a managed enterprise offering with quote-based pricing. | Composable input and output guards backed by prebuilt Hub validators, custom validators, and structured-output validation. | Risks covered by installed or custom validators, including PII, toxicity, prompt injection, schema violations, and output-quality requirements. | Inline failure actions can reask the model, apply a fix, filter content, return no response, raise an exception, or call custom logic. | Validation results and call history are available within the framework. Aggregate production analysis, controlled experiments, and regression datasets require integrations or a separate evaluation system. |
| Check Point AI Guardrails | Commercial runtime security service, previously known as Lakera Guard. Pricing is available through sales. | Security-focused detection across prompts, retrieved content, model responses, and agent tool interactions. | Prompt injection, jailbreaks, data leakage, PII, content violations, malicious links, off-policy tool use, and custom threats. | The Guard API flags interactions in the request path. Applications can block the interaction, log the finding, or mask sensitive information according to the configured policy. | Includes runtime monitoring and a policy simulator that analyzes up to 30 days of historical traffic. Scored model and prompt experiments and regression datasets sit outside the Guard API workflow. |
| OpenAI Moderation | Free managed API endpoint. | Multimodal content moderation for text and images without hosting a separate classifier. | Predefined harm categories covering areas such as harassment, hate, illicit activity, self-harm, sexual content, and violence. Image support is limited to applicable categories. | Returns category flags and scores. The application decides whether to allow, review, or block the content. | Provides results for each request. Custom policies, historical accuracy measurement, experiments, and dataset feedback require a separate evaluation layer. |
| Amazon Bedrock Guardrails | Managed AWS service with usage-based pricing for each enabled safeguard. | Configurable safeguards that can be applied to Bedrock models or used independently through the ApplyGuardrail API. | Harmful content, prompt attacks, denied topics, PII, blocked words, contextual grounding, and claims covered by Automated Reasoning policies. | Can block prompts, replace responses with configured messaging, or mask sensitive information. ApplyGuardrail can evaluate content at different points in the application flow. | Draft testing and versioning are included. CloudWatch tracks invocations, latency, errors, usage, and intervention counts, while accuracy evaluation and regression datasets require a separate process. |
Braintrust provides the strongest evaluation workflow in this comparison by carrying guardrail scorers from pre-deployment experiments into production monitoring and regression datasets. Policies that require pre-response blocking can use an inline control alongside Braintrust.
Getting started with guardrails in Braintrust
Everything in the pipeline above runs from a single Braintrust project. Define the scorer, point online scoring at your production traces, and route violations to Slack or a webhook. Confirmed failures can then be added to a dataset for regression testing in future releases.
Teams at Notion, Stripe, Vercel, Zapier, and Ramp use Braintrust for production AI evaluation and observability. Notion, for example, turns language-adherence failures into datasets and evaluates them with LLM-as-a-judge scorers to prevent regressions. The free Starter plan includes 1 GB of processed data, 10,000 custom scores per month, and unlimited users, projects, datasets, and experiments, with no credit card required.
Start building your first guardrail with Braintrust →
FAQs about LLM guardrails (2026)
What is the difference between LLM guardrails and evals?
LLM evals measure qualities such as accuracy, helpfulness, tone, cost, and task completion across test cases or production traces. Guardrails focus on policies whose violation requires a defined response, such as blocking personal data, flagging unsafe medical advice, or escalating a prompt-injection attempt. A quality scorer may inform product improvements, while a guardrail scorer connects its result to blocking, redaction, review, or alerting.
Do I need a separate guardrails product?
The need for a separate product depends on response timing and policy ownership. Security teams may require a managed runtime service to detect prompt injection or data leakage before a request reaches the model, especially when the same controls must apply across several applications. Rules covering approved claims, required disclosures, tone, or prohibited advice can be written and monitored as Braintrust scorers. When both layers are used, the runtime service handles request-time intervention, while Braintrust measures policy performance across experiments and production traffic.
How fast can guardrails catch violations?
An inline guardrail evaluates content before the request continues, so its detection time adds directly to the application's response latency. Braintrust online scoring begins after a production trace is logged and runs asynchronously, leaving the user-facing request unaffected. Braintrust processes log alerts in batches with a minimum notification interval of five minutes, which supports investigations, notifications, session quarantining, and other follow-up actions. Any policy that must stop harmful content before delivery requires an inline guardrail.
How do guardrails relate to prompt injection and red teaming?
Prompt-injection guardrails screen live inputs, retrieved content, model outputs, and tool interactions for attack patterns. Red teaming actively tries to make the complete application reveal secrets, ignore instructions, or misuse connected tools across multi-step scenarios. Successful attacks and their expected safe behavior can be stored in a Braintrust dataset, then rerun after changes to the model, prompts, retrieval pipeline, or tool configuration. Repeating the same attack set shows whether a release has reopened a previously fixed vulnerability.