Skip to main content
Guardrails actively intervene in your LLM application’s behavior based on scores from LLM judges. They run in real time before outputs reach users and can block or modify responses when scores exceed thresholds. You can use guardrails to block toxic content, filter responses for Personally Identifiable Information (PII), or block abusive input from users.

How Weave guardrails work

Weave guardrails use inline Weave Scorers to assess the input from a user or the output from an LLM and adjust the LLM’s responses in real time. You can configure custom scorers or use built-in scorers to assess content for a variety of purposes. This guide demonstrates how to use both types of scorers as guardrails. If you want to passively score production traffic without modifying your application’s control flow, use monitors instead. Unlike monitors, guardrails require code changes because they affect your application’s control flow. However, every scorer result from guardrails is automatically stored in Weave’s database, so your guardrails also function as monitors without any extra configuration. You can analyze historical scorer results regardless of how they were originally used.
The Weave TypeScript SDK does not support the tools required to set up guardrails.

Optimize your Weave guardrail performance

Because guardrails can interrupt your application’s control flow and change the course of its responses, they can negatively impact performance if they’re too complex. For optimal performance, we recommend:
  • Keeping guardrail logic simple and fast
  • Caching common results
  • Avoiding heavy external API calls
  • Initializing guardrails outside of your main functions to avoid repeated initialization costs
Initializing your guardrails outside of the main function is particularly important when:
  • Your scorers load ML models
  • You’re using local LLMs where latency is critical
  • Your scorers maintain network connections
  • You have high-traffic applications

Example: Create a guardrail using a built-in moderation scorer

The following example sends user prompts to OpenAI’s GPT-4o mini model. The model’s response is then passed to Weave’s OpenAI’s moderation API to assess whether the LLM’s response contains harmful or toxic content. The model’s response is passed to the guardrail function (generate_safe_response()) where uses the OpenAIModerationScorer to check the LLM’s original response. The function’s logic then checks OpenAI’s assessment response for a boolean in the passed field, which determines how the application responds.
When using LLM-as-a-judge scorers, you can reference variables from your ops in your scoring prompts. For example, “Evaluate whether {output} is accurate based on {ground_truth}.” See prompt variables for more information.

Example: Create a guardrail using a custom scorer

The following example creates a custom guardrail that detects personally identifiable information (PII) in LLM responses, such as email addresses, phone numbers, or social security numbers. This prevents sensitive information from being exposed in generated content. The function generate_safe_response applies the custom PIIDetectionScorer.

Integrate Weave with AWS Bedrock Guardrails

The BedrockGuardrailScorer uses AWS Bedrock Guardrails to detect and filter content based on configured policies. Before setting up a Bedrock Guardrails integration, you need: You don’t need to create your own Bedrock client. Weave creates it for you. To specify a region, pass the region value in the scorer’s bedrock_runtime_kwargs parameter. For an example of how to create a guardrail in AWS Bedrock, see the Bedrock guardrails notebook. The following example checks text generation against AWS Bedrock Guardrails policies before returning results to users: