Overview
Guardrails in Bifrost provide enterprise-grade content safety, security validation, and policy enforcement for LLM requests and responses. The system validates inputs and outputs in real-time against your specified policies, ensuring responsible AI deployment with comprehensive protection against harmful content, prompt injection, PII leakage, and policy violations.
Supported Providers
AWS Bedrock Guardrails
Enterprise content filtering, PII detection, and prompt attack prevention.
Azure Content Safety
Multi-modal content moderation with severity-based filtering.
GraySwan Cygnal
AI safety monitoring with natural language rule definitions.
Patronus AI
LLM security, hallucination detection, and safety evaluation.
Core Concepts
Bifrost Guardrails are built around two core concepts that work together to provide flexible and powerful content protection:| Concept | Description |
|---|---|
| Rules | Custom policies defined using CEL (Common Expression Language) that determine what content to validate and when. Rules can apply to inputs, outputs, or both, and can be linked to one or more profiles for evaluation. |
| Profiles | Configurations for external guardrail providers (AWS Bedrock, Azure Content Safety, GraySwan, Patronus AI). Profiles are reusable and can be shared across multiple rules. |
- Profiles define how content is evaluated using external provider capabilities
- Rules define when and what content gets evaluated using CEL expressions
- A single rule can use multiple profiles for layered protection
- Profiles can be reused across different rules for consistency
Key Features
| Feature | Description |
|---|---|
| Multi-Provider Support | AWS Bedrock, Azure Content Safety, GraySwan, and Patronus AI integration |
| Dual-Stage Validation | Guard both inputs (prompts) and outputs (responses) |
| Real-Time Processing | Synchronous and asynchronous validation modes |
| CEL-Based Rules | Define custom policies using Common Expression Language |
| Reusable Profiles | Configure providers once, use across multiple rules |
| Sampling Control | Apply rules to a percentage of requests for performance tuning |
| Automatic Remediation | Block, redact, or modify content based on policy |
| Comprehensive Logging | Detailed audit trails for compliance |
Navigating Guardrails in the UI
Access Guardrails from the Bifrost dashboard:| Page | Path | Description |
|---|---|---|
| Configuration | Guardrails > Configuration | Manage guardrail rules and their settings |
| Providers | Guardrails > Providers | Configure and manage guardrail profiles |
Architecture
The following diagram illustrates how Rules and Profiles work together to validate LLM requests: Flow Description:- Incoming Request - LLM request arrives at Bifrost
- Input Validation - Applicable rules evaluate the input using linked profiles
- LLM Processing - If input passes, request is forwarded to the LLM provider
- Output Validation - Response is evaluated by output rules using linked profiles
- Response - Validated response is returned (or blocked/modified based on violations)
Guardrail Rules
Guardrail Rules are custom policies that define when and how content validation occurs. Rules use CEL (Common Expression Language) expressions to evaluate requests and can be linked to one or more profiles for execution.
Rule Properties
| Property | Type | Required | Description |
|---|---|---|---|
id | integer | Yes | Unique identifier for the rule |
name | string | Yes | Descriptive name for the rule |
description | string | No | Explanation of what the rule does |
enabled | boolean | Yes | Whether the rule is active |
cel_expression | string | Yes | CEL expression for rule evaluation |
apply_to | enum | Yes | When to apply: input, output, or both |
sampling_rate | integer | No | Percentage of requests to evaluate (0-100) |
timeout | integer | No | Execution timeout in milliseconds |
provider_config_ids | array | No | IDs of profiles to use for evaluation |
Creating Rules
- Web UI
- API
- config.json
- Helm
- Navigate to Rules
- Go to Guardrails > Configuration
- Click Add Rule

- Configure Rule Settings
- Name: Enter a descriptive name (e.g., “Block PII in Prompts”)
- Description: Explain the rule’s purpose
- Enabled: Toggle to activate the rule
- Apply To: Select when to apply the rule
input- Validate incoming prompts onlyoutput- Validate LLM responses onlyboth- Validate both inputs and outputs
- CEL Expression: Define the validation logic
- Sampling Rate: Set percentage of requests to evaluate (default: 100%)
- Timeout: Set maximum execution time in milliseconds
-
Link Profiles
- Select one or more profiles to use for evaluation
- Rules will execute all linked profiles in sequence
-
Save and Test
- Click Save Rule
- Use the Test button to validate with sample content
CEL Expression Examples
CEL (Common Expression Language) provides a powerful way to define rule conditions. Here are common patterns: Always Apply Rule:Linking Rules to Profiles
Rules can be linked to multiple profiles for comprehensive validation:
- Link PII detection rules to profiles with PII capabilities (Bedrock, Patronus)
- Link content filtering rules to profiles with content safety features (Azure, Bedrock, GraySwan)
- Use GraySwan for custom natural language rules when you need flexible, readable policies
- Use multiple profiles for defense-in-depth (e.g., Bedrock + Patronus for PII, Azure + GraySwan for content)
- Set appropriate timeouts when using multiple profiles
Managing Profiles
Profiles are reusable configurations for external guardrail providers. Each profile contains provider-specific settings including credentials, endpoints, and detection thresholds.
Profile Properties
| Property | Type | Required | Description |
|---|---|---|---|
id | integer | Yes | Unique identifier for the profile |
provider_name | string | Yes | Provider type: bedrock, azure, grayswan, patronus_ai |
policy_name | string | Yes | Descriptive name for the policy |
enabled | boolean | Yes | Whether the profile is active |
config | object | No | Provider-specific configuration |
Creating Profiles
- Web UI
- API
- config.json
- Helm
- Navigate to Providers
- Go to Guardrails > Providers
- Click Add Profile

-
Select Provider Type
- Choose from: AWS Bedrock, Azure Content Safety, GraySwan, or Patronus AI
-
Configure Provider Settings
- Enter credentials and endpoint information
- Configure detection thresholds and actions
- See provider-specific setup sections above for detailed configuration
-
Save Profile
- Click Save Profile
- The profile is now available for linking to rules
Provider Capabilities
Each provider offers different capabilities. Choose profiles based on your validation needs:| Capability | AWS Bedrock | Azure Content Safety | GraySwan | Patronus AI |
|---|---|---|---|---|
| PII Detection | Yes | No | No | Yes |
| Content Filtering | Yes | Yes | Yes | Yes |
| Prompt Injection | Yes | Yes | Yes | Yes |
| Hallucination Detection | No | No | No | Yes |
| Toxicity Screening | Yes | Yes | Yes | Yes |
| Custom Policies | Yes | Yes | Yes | Yes |
| Custom Natural Language Rules | No | No | Yes | No |
| Image Support | Yes | No | No | No |
| IPI Detection | No | Yes | Yes | No |
| Mutation Detection | No | No | Yes | No |
Best Practices
Profile Organization:- Create separate profiles for different use cases (PII, content filtering, etc.)
- Use descriptive policy names that indicate the profile’s purpose
- Keep credentials secure using environment variables
- Enable only the profiles you need to minimize latency
- Use sampling rates on rules for high-traffic endpoints
- Set appropriate timeouts to prevent slow requests
- Store API keys and credentials in environment variables or secrets managers
- Regularly rotate credentials
- Use least-privilege IAM roles for AWS Bedrock

