For the complete documentation index, see llms.txt. This page is also available as Markdown.

Guardrails

Add deterministic and LLM-based guardrails to protect your AI applications from unwanted behaviors and ensure compliance.

Introduction

Guardrails in FastRouter allow you to validate and monitor requests and responses flowing through your LLM gateway. They help you:

  • Prevent sensitive information (PII) from being exposed

  • Detect prompt injection and jailbreak attempts before they reach the model

  • Ensure responses adhere to specific topics or formats

  • Block toxic or inappropriate content

  • Validate output structure (regex patterns)

⚠️ Feature Note

Guardrails do not support streaming (stream=true). Ensure that stream=false in your request payload when using guardrails.

Guardrail Actions

Each guardrail can be configured with one of two actions that determine how the system behaves when a guardrail check fails:

Action
Default State
Behavior
Use Case

Validate

Applies to both request and response. If any guardrail check fails, the request is killed with status code 446. If all guardrail checks succeed, the request/response proceeds with status code 200.

Use when guardrails are critical and a failed check should block the request entirely. Recommended: Test on a subset of requests first to understand the impact.

Observe

✓ Default

Applies to both request and response. If any guardrail check fails, the request still proceeds but with status code 246. If all guardrail checks succeed, the request/response proceeds with status code 200.

Use when you want to log guardrail results without affecting your application flow. Ideal for monitoring and gathering insights before enforcing strict validation.

⚠️ Testing Recommendation

We strongly recommend running guardrails in Observe mode first on a subset of your requests to understand their impact before switching to Validate mode.

Status Codes

FastRouter uses specific status codes to communicate guardrail results:

Status Code
Description

200

All guardrail checks passed. Request/response processed successfully.

246

Observe mode: One or more guardrail checks failed, but the request/response was still processed. Check logs for details.

446

Validate mode: One or more guardrail checks failed. Request was blocked and not processed.

Using Guardrails in Requests

After creating guardrails in the FastRouter dashboard, you'll receive a Config ID (e.g., gr_a8f3k9m2) for each guardrail. Use these IDs to apply guardrails to your requests:

Adding Guardrails to Requests

Include the input_guardrails and/or output_guardrails parameters in your request body with an array of guardrail config IDs:

In this example:

  • input_guardrails - Applied to the incoming user request before it's sent to the LLM

  • output_guardrails - Applied to the LLM's response before returning it to your application

Multiple Guardrails

You can apply multiple guardrails at each stage. They will be evaluated in the order specified:

Input guardrails above are Prompt Injection, Topic Adherence and PII Check. Output guardrails are Toxicity Detection and Competitor Mention.

💡 Ordering Tip

Place deterministic guardrails (Prompt Injection, RegEx Check) before LLM Judge guardrails in the array. A block from a fast, zero-cost check avoids paying for a judge call on a request you were going to reject anyway.

Guardrail Types

Basic Guardrails

Deterministic guardrails that run in milliseconds and don't require LLM evaluation:

  • RegEx Check - Validate content against custom regex patterns

  • Prompt Injection - Detect instruction-override, jailbreak and prompt-extraction attempts in user input (input stage only)

LLM Judge Guardrails

Intelligent guardrails that use LLM evaluation for complex checks:

  • PII Check - Detect and optionally redact emails, phone numbers, SSN, credit cards

  • Topic Adherence - Ensure conversations stay on allowed topics

  • Toxicity Detection - Detect hate speech, harassment, violence, and inappropriate content

💡 Performance Note

Basic guardrails execute in milliseconds and consume no tokens. LLM Judge guardrails require an additional LLM call and may add 500ms-2s latency depending on your Default Guardrails Key configuration.


Prompt Injection

The Prompt Injection guardrail is a Basic (deterministic) guardrail that inspects incoming user content for attempts to override your system instructions, unlock a "developer mode", extract your system prompt, forge role boundaries, or smuggle any of the above past a filter.

It is available at the Input stage only. Applying it to output has no effect.

Because it runs no model call, it adds no token cost and typically completes in single-digit milliseconds.

What it detects

Detection is organised into ten rule categories, plus a set of evasion detectors that catch hidden versions of the same content.

Category
What it covers

Direct Instruction Override

Attempts to discard or discredit the instructions already in force.

Developer / Admin Mode

Requests to enter a privileged, unlocked, or debug mode.

System Override

Attempts to replace, supersede or fake the boundaries of the system prompt.

Prompt Extraction

Attempts to make the model emit its own instructions verbatim.

Role Manipulation

Attempts to redefine what the model is or assert that it has no constraints.

Jailbreak Personas

Named jailbreaks and fiction framing used to launder a restricted request.

Safety Bypass

Attempts to disable, evade or suppress safety behaviour, including refusal suppression.

Tag Injection and Role Spoofing

Forged markup or role delimiters that fake a turn boundary.

Control Token Injection

Provider control tokens and template placeholders that a downstream renderer might expand.

Evasion

Instructions to decode and then act on a hidden payload.

Configuration

Setting
Description

Name

A descriptive name for the guardrail.

Action

Observe (default) or Validate.

Stage

Input. Prompt Injection is not available at the output stage.

Disabled rules

A list of rule IDs to exclude from evaluation. Use this to suppress a rule that produces false positives in your traffic without disabling the guardrail.

Every rule, including the evasion detectors, can be individually disabled.

Handling false positives

The rule set is written to be narrow, but some legitimate applications will trip it. Common sources:

  • Transcript and log analysis. Applications that pass conversation logs, support tickets or chat exports to the model will match role-delimiter and bracketed-label rules. These are corroborating rules and will not block on their own, but they will appear in your logs.

  • Security and red-team tooling. Applications whose subject matter is prompt injection — vulnerability triage, moderation review, safety research — will match by design.

  • Code and markup payloads. Requests containing XML, chat-template code, or provider SDK examples may match tag and control-token rules.

Recommended approach:

  1. Run the guardrail in Observe mode and let it accumulate traffic.

  2. Filter your logs for status 246 and review which rule IDs recur.

  3. Add persistently noisy rule IDs to Disabled rules.

  4. Switch to Validate once the false-positive rate is acceptable.

⚠️ Do not echo guardrail details to end users

The checks payload names the rules that matched. Surfacing that to an untrusted end user hands them a feedback loop for iterating around the filter. Log it; don't render it. Return a generic message to the user instead.

Scope and limitations

The Prompt Injection guardrail is a defence-in-depth signal, not a security boundary. It is pattern-based, and pattern-based detection cannot enumerate every phrasing of an adversarial instruction — particularly novel phrasings, non-English payloads, and injections that arrive indirectly through retrieved documents or tool output rather than through the user turn.

Use it alongside, not instead of:

  • Least-privilege tool and data access for the model

  • Treating retrieved content and tool results as untrusted input

  • Output-stage guardrails on anything the model returns

  • Human review on high-consequence actions

The rule set is updated continuously as new techniques emerge. Rule IDs are stable; the underlying detection logic is not versioned and may change without notice.

Example

Response (446 — Validate mode, request blocked):


Creating Guardrails

To create a new guardrail:

  1. Navigate to Guardrails in your FastRouter dashboard

  2. Click the Browse Templates tab

  3. Choose a template and click Create

  4. Configure your guardrail settings:

    • Name - A descriptive name for your guardrail

    • Action - Choose Observe or Validate

    • Stage - Choose Input or Output

    • Template-specific settings (e.g., PII types, word limits, regex patterns, disabled rules)

  5. Click Create Guardrail

  6. Copy the generated Config ID to use in your requests

Best Practices

  • Start with Observe mode - Monitor guardrail behavior before enforcing validation

  • Test incrementally - Apply guardrails to a small percentage of traffic first

  • Layer guardrails - Use both Basic and LLM Judge guardrails for comprehensive protection

  • Run deterministic checks first - Prompt Injection and RegEx cost nothing and fail fast

  • Monitor costs - LLM Judge guardrails consume tokens from your Default Guardrails Key

  • Keep guardrails focused - Create specific guardrails for specific use cases rather than one large guardrail

  • Review logs regularly - Check status 246 responses to understand when guardrails are triggered

  • Don't rely on injection detection alone - Pair it with least-privilege tool access and output-stage validation

Example: Complete Request Flow

Response (200 — all checks passed):

Response (246 — check failed in Observe mode). The request is still processed, but the guardrail logs the failure:

Response (446 — check failed in Validate mode). The request is blocked:

Last updated