Guardrails
Deploy pre-call and post-call guardrails in nRouter to prevent prompt injections, enforce content safety policies, and redact sensitive PII data in real time.
Last updated
Guardrails inspect requests before they reach a model (pre-call) and responses before they reach your user (post-call). They can block, redact, warn, or simply log — letting you enforce safety and compliance without changing your application code.
Guardrail types
| Type | What it does |
|---|---|
| Presidio PII | Detects and anonymizes personally identifiable information using Microsoft Presidio |
| Regex | Filters content matching patterns you define |
| Keyword | Blocks content containing words on a blocklist |
| Prompt Injection | Detects and blocks attempts to hijack the model's instructions |
| Custom | Calls your own webhook to make the decision |
Modes and actions
Each guardrail runs in a mode — pre-call (before the LLM request) or post-call (on the response) — and takes an action when it triggers:
| Action | Effect |
|---|---|
| Block | Reject the request before it reaches the provider — it costs zero credits and never appears in the provider's logs |
| Redact | Strip the sensitive content and continue |
| Warn | Allow the request through, but attach a warning header |
| Log | Allow through and record the event only |
Scope hierarchy
Guardrails apply at three scopes, combined per request — key > team > org:
- Organization — a master kill-switch plus org-wide guardrails that apply to every key.
- Team — guardrails scoped to a team, applying to every key on that team.
- Key — guardrails assigned to specific virtual keys.
Scopes resolve by specificity, not union: for each guardrail, the assignment at the narrowest scope that mentions it decides, and that row alone. A key-level assignment overrides its team's and org's rather than adding to them. Guardrails that no assignment mentions are untouched, so different guardrails on the same request can be decided at different scopes.
In practice today every assignment the dashboard creates is an enabled one, and removing an assignment deletes the row rather than disabling it — so a narrower scope currently tightens or re-points protection and does not remove it. The distinction matters if that ever changes: because the narrowest row decides alone, a disabled assignment at the winning scope would switch that guardrail off for the key even though the broader org row still exists. It would not be overruled by the wider rule.
Manage org guardrails on the main Guardrails page and per-key assignments under Guardrails → Keys.
Testing before you ship
Expand any guardrail to find a Test tab: paste sample input and see exactly which action fires and how long it took. This lets you tune a rule against realistic content before it touches live traffic.
Versioning and rollback
Every change to a guardrail is snapshotted. The Versions tab lists each update, and you can roll back to any prior version with one click — useful if a tightened rule starts blocking legitimate requests.
Templates
The Templates gallery offers one-click setups for common patterns — PII redaction, jailbreak/prompt-injection detection, and language blocklists — so you can stand up sensible defaults quickly, then customize.
Guardrail logs
The Guardrails → Logs view records every guardrail evaluation:
| Column | Meaning |
|---|---|
| Time | When the guardrail ran |
| Guardrail | Which rule evaluated the request |
| Mode | Pre-call or post-call |
| Action | Blocked, Redacted, Allowed, Logged, or Error |
| Latency | How long the check took (ms) |
| Request ID | Correlate with the request in observability logs |
Filter by guardrail or action, or search by name/request ID.
Next steps
- Observability & Logs — See guardrail outcomes alongside the full request
- API Key Management — Assign guardrails to specific keys
- Playground — Trigger a guardrail interactively to confirm it fires
FAQ
Do I need to change my application code to use guardrails?
No. Guardrails run in the request path automatically once configured — they inspect requests before they reach a model and responses before they reach your user, with no SDK or code change on your side.
What kinds of content can a guardrail check for?
There are five types: Presidio PII detection/anonymization, Regex pattern filtering, Keyword blocklists, Prompt Injection detection, and Custom — which calls your own webhook to make the decision. You can combine multiple guardrails across the same request.
What's the difference between the Block, Redact, Warn, and Log actions?
Block rejects the request before it reaches the provider, Redact strips the sensitive content and lets the request continue, Warn allows it through but attaches a warning header, and Log allows it through and only records the event. Each guardrail runs in either pre-call (before the model) or post-call (on the response) mode.
If a guardrail blocks a request, am I still charged credits for it?
No. A blocked request is rejected before it reaches the provider, so it costs zero credits and never appears in the provider's logs. Redact, Warn, and Log all let the request proceed, so those calls are billed normally.
How do organization, team, and key guardrails combine on a single request?
The narrowest scope that mentions a guardrail decides it, in the order key > team > org > org default. A key assignment overrides team, team overrides org, and a disable at the winning scope turns that guardrail off — it is not re-enabled by a broader assignment still existing. Guardrails no assignment mentions are unaffected, so different guardrails on one request can be decided at different scopes.
Who on my team can create or edit guardrails?
Creating, editing, deleting, and rolling back guardrails requires the owner or admin role. Any org member can view guardrails and their version history, and any member can use the Test tab to try a rule against sample input.
Can I test a guardrail before it affects live traffic?
Yes. Expand any guardrail and open the Test tab, paste sample input, and you'll see exactly which action fires and how long the check took — so you can tune a rule against realistic content before it touches live traffic.
What happens if I tighten a rule and it starts blocking legitimate requests?
Every change to a guardrail is snapshotted. Open the Versions tab, and you can roll back to any prior version with one click to immediately restore the earlier behavior.
Is there a fast way to stand up common guardrails?
Yes. The Templates gallery offers one-click setups for common patterns — PII redaction, jailbreak/prompt-injection detection, and language blocklists — that you can apply as sensible defaults and then customize.
How do I see what my guardrails did, and can I trace it back to a specific request?
The Guardrails → Logs view records every evaluation with its time, which rule ran, the mode, the action taken (Blocked, Redacted, Allowed, Logged, or Error), and the latency in milliseconds. You can filter by guardrail or action, or use the Request ID to correlate an evaluation with the full request in your observability logs.
Prompt Management
Manage, version, test, and deploy enterprise prompt templates directly within nRouter. Streamline collaboration and iterate on AI prompt engineering workflows.
Analytics & Reports
Analyze LLM spend, token volume, model latency, and error trends with nRouter advanced analytics. Generate team-level reports to optimize inference costs.