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:
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:
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 LLMoutput_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.
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
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:
Run the guardrail in Observe mode and let it accumulate traffic.
Filter your logs for status
246and review which rule IDs recur.Add persistently noisy rule IDs to Disabled rules.
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:
Navigate to Guardrails in your FastRouter dashboard
Click the Browse Templates tab
Choose a template and click Create
Configure your guardrail settings:
Name - A descriptive name for your guardrail
Action - Choose
ObserveorValidateStage - Choose
InputorOutputTemplate-specific settings (e.g., PII types, word limits, regex patterns, disabled rules)
Click Create Guardrail
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
246responses to understand when guardrails are triggeredDon'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
