Guardrails

Overview

Guardrails are a pipeline of rules that run before a request reaches any LLM provider. They can inspect, modify, or reject requests — giving you centralized control over every prompt that flows through Aurora.

OSS guardrails include system_prompt rules and additional rule types: llm_based_altering for content rewriting via an auxiliary LLM, regex_block for pattern-based blocking, pii_redact for PII redaction, and length_limit for token/character caps. For Enterprise-only guardrail features (response-side rewriting, additional rule types in future releases), see Enterprise Guardrails.

Guardrails work across all text-based endpoints:

• /v1/chat/completions
• /v1/responses

Quick Start

Add a guardrails section to your config/config.yaml:

guardrails:
  enabled: true
  rules:
    - name: "safety-prompt"
      type: "system_prompt"
      order: 0
      system_prompt:
        mode: "decorator"
        content: "Always respond safely and respectfully."
 

That's it. Every request now gets the safety prompt prepended to its system instructions.

How It Works

1. Messages are extracted from the incoming request into a normalized format
2. The guardrails pipeline processes the messages (inject, modify, or reject)
3. Modified messages are applied back to the original request
4. The request continues to the LLM provider

Guardrails never see the raw API request types — they operate on a normalized message list. This means the same guardrail works identically for /chat/completions and /responses.

Execution Order

Each guardrail has an order value that controls when it runs:

• Same order → run in parallel (concurrently)
• Different order → run sequentially (ascending)

Each sequential group receives the output of the previous group. If any guardrail returns an error, the request is rejected and never reaches the provider.

Configuration

Full Structure

guardrails:
  enabled: true    # Master switch (default: false)
  rules:
    - name: "rule-name"         # Unique identifier for this instance
      type: "system_prompt"     # Guardrail type
      user_path: "/team/privacy" # Optional base path for internal auxiliary calls
      order: 0                  # Execution order
      system_prompt:            # Type-specific settings
        mode: "decorator"
        content: "Your prompt text here."
 

Environment Variable

You can toggle guardrails without editing the config file:

export GUARDRAILS_ENABLED=true
 

Rule Fields

Guardrail Types

OSS guardrails support the system_prompt, llm_based_altering, regex_block, pii_redact, and length_limit types. For Enterprise guardrail capabilities, see Enterprise Guardrails.

system_prompt

Adds, replaces, or decorates the system prompt on every request.

llm_based_altering

Rewrites content via an auxiliary LLM provider for content safety or style normalization. Configure the backing provider and system instruction for the rewriting model.

regex_block

Blocks or sanitizes content matching one or more regular expression patterns. Useful for preventing prompt injection, blocking specific formats, or enforcing content policies.

pii_redact

Automatically detects and redacts personally identifiable information (email addresses, phone numbers, SSNs, credit card numbers) from request and response content. Supports configurable redaction strategies.

length_limit

Enforces maximum character or estimated-token limits on request and response content. Configurable per direction (input, output, or both).

Settings

Modes

    - name: "default-system"
      type: "system_prompt"
      order: 0
      system_prompt:
        mode: "inject"
        content: "You are a helpful assistant."
 

Examples

Single Safety Guardrail

The simplest setup — add a safety prefix to every request:

guardrails:
  enabled: true
  rules:
    - name: "safety"
      type: "system_prompt"
      order: 0
      system_prompt:
        mode: "decorator"
        content: "Always be safe, respectful, and helpful."
 

Multiple Guardrails in Parallel

Two guardrails running at the same order execute concurrently:

guardrails:
  enabled: true
  rules:
    - name: "safety-prompt"
      type: "system_prompt"
      order: 0
      system_prompt:
        mode: "decorator"
        content: "Always be safe and respectful."
 
    - name: "compliance-prompt"
      type: "system_prompt"
      order: 0
      system_prompt:
        mode: "inject"
        content: "Follow all company compliance policies."
 

Sequential Pipeline

Guardrails with different orders run one after another. Later groups see the output of earlier ones:

guardrails:
  enabled: true
  rules:
    # Step 1: ensure a system prompt exists
    - name: "default-system"
      type: "system_prompt"
      order: 0
      system_prompt:
        mode: "inject"
        content: "You are a helpful assistant."
 
    # Step 2: decorate whatever system prompt is now present
    - name: "safety-prefix"
      type: "system_prompt"
      order: 1
      system_prompt:
        mode: "decorator"
        content: "[SAFETY] Always respond within company guidelines."
 
    # Step 3: add a final compliance check after decoration
    - name: "compliance-stamp"
      type: "system_prompt"
      order: 2
      system_prompt:
        mode: "override"
        content: "[COMPLIANCE REVIEW] Respond according to company policy."
 

Mixed Parallel and Sequential

guardrails:
  enabled: true
  rules:
    # Order 0: these two run in parallel
    - name: "safety"
      type: "system_prompt"
      order: 0
      system_prompt:
        mode: "decorator"
        content: "Be safe."
 
    - name: "policy"
      type: "system_prompt"
      order: 0
      system_prompt:
        mode: "inject"
        content: "Follow company policy."
 
    # Order 1: runs after both order-0 guardrails complete
    - name: "final-override"
      type: "system_prompt"
      order: 1
      system_prompt:
        mode: "decorator"
        content: "[FINAL CHECK]"
 

Per-type examples

OSS supports five guardrail types. system_prompt is covered above. The other four need their own concrete examples.

pii_redact

Detects and masks PII with deterministic regexes. The built-in kinds are email, phone, ssn, and credit_card. Each match is replaced with a fixed token like [EMAIL_REDACTED]. The guardrail never rejects the request — it only rewrites the messages.

guardrails:
  enabled: true
  rules:
    - name: "redact-emails-and-phones"
      type: "pii_redact"
      order: 0
      pii_redact:
        kinds: ["email", "phone"]   # default: all four
        roles: ["user"]             # only redact user messages; default: all roles
 
    - name: "redact-pii-on-assistant-responses"
      type: "pii_redact"
      order: 5
      pii_redact:
        kinds: ["ssn", "credit_card"]
        roles: ["assistant"]

A request with "My email is alice@example.com" becomes "My email is [EMAIL_REDACTED]" after the guardrail runs. The replacement happens before the upstream call, so providers never see the raw PII.

regex_block

Blocks or sanitizes messages that match a regular expression. Two actions: block (returns 400 to the client) or sanitize (replaces the match with the configured replacement string).

guardrails:
  enabled: true
  rules:
    # Block obvious prompt-injection attempts
    - name: "block-injection"
      type: "regex_block"
      order: 0
      regex_block:
        action: "block"
        patterns:
          - "(?i)ignore (all|any) previous instructions"
          - "(?i)disregard your (system|initial) prompt"
 
    # Sanitize internal project codenames out of the request
    - name: "sanitize-codenames"
      type: "regex_block"
      order: 1
      regex_block:
        action: "sanitize"
        replacement: "[REDACTED]"
        patterns:
          - "Project\\s+(?:Atlas|Borealis|Cinder)"
          - "\\bSKU-\\d{4,}\\b"

block returns 400 to the client without ever calling the provider. sanitize rewrites the match in place and continues. Patterns are compiled at startup; invalid Go regex is rejected at load time.

length_limit

Rejects requests whose total message content exceeds a character or estimated-token cap. The character count is the sum of every message's text content; the token estimate is chars / 4. The guardrail rejects with a 400.

guardrails:
  enabled: true
  rules:
    - name: "cap-user-input"
      type: "length_limit"
      order: 0
      length_limit:
        max_chars: 32000
        # max_estimated_tokens: 8000   # alternative or both

Set max_chars to a hard character limit, max_estimated_tokens to a soft token estimate, or both (whichever is exceeded first triggers the block).

llm_based_altering

Uses an auxiliary model call to rewrite content. Configure which provider/model performs the rewrite and what instruction it follows. Use this for content-style normalization, language translation, or moderation that simple regexes cannot do.

guardrails:
  enabled: true
  rules:
    - name: "normalize-style"
      type: "llm_based_altering"
      order: 0
      llm_based_altering:
        model: "openai-primary/gpt-4o-mini"   # the model that does the rewriting
        role: "user"                            # which message role to rewrite; default: "user"
        instruction: "Rewrite the message in plain, neutral English. Strip profanity and personal opinions."
 
    - name: "translate-to-english"
      type: "llm_based_altering"
      order: 1
      llm_based_altering:
        model: "anthropic-prod/claude-haiku-4-5"
        role: "user"
        instruction: "Translate the user message to English. Preserve technical terms."

How It Works With Different Endpoints

For Enterprise guardrail capabilities (response-side rewriting, additional rule types), see Enterprise Guardrails.

Guardrails operate on a normalized message format internally. The adaptation between API-specific request types and this format happens automatically:

Errors and Rejection

If a guardrail returns an error, the request is rejected immediately. The error is returned to the client and the request never reaches the LLM provider.

This is useful for future guardrail types that validate content (e.g., PII detection, content filtering). The system prompt guardrail does not reject requests — it only modifies them.