AI guardrails
Every prompt is inspected before any model sees it
Guardrails here are not a report you read after the incident - they run inside the request path, per API key, and a request that fails them never reaches a provider.
- Injection patterns matched after evasions are decoded - base64, hex, letter-scrambling and invisible characters are undone first
- Sensitive data detected and redacted before the provider is called - the model never sees what the guardrail removed
- Model, provider and region access enforced per key, so a leaked key is bounded, not blank cheque
What are AI guardrails?
AI guardrails are rules that stand between your users and the model: what may be asked, what may be sent, which models may answer, and what must never leave the building inside a prompt. The defining question is where they run. Guardrails that scan logs afterwards produce incident reports; guardrails that run in the request path produce prevented incidents.
Final Router's guardrails run in the path. They attach to API keys, so different products and customers carry different rules on the same account - and every enforcement is visible in the request log, because a rule that acts silently is a rule nobody can debug.
What the guardrails actually check
Each card ends with the concrete behaviour, because 'enterprise-grade security' is not a claim - these are.
Injection detection that decodes evasions
Attackers do not write 'ignore all previous instructions' in the clear - they base64 it, hex it, scramble letters or hide it in invisible characters. The detectors undo the disguise before the patterns run.
decode first, match second - on every guarded request
Sensitive-data redaction
Emails, keys and secrets found in prompts are redacted before the provider call - and the redacted text is what gets sent, verified end-to-end against providers that echo input back.
the provider receives the redacted prompt, not the original
Rules attach to keys
One product gets strict inspection, an internal tool gets none, a customer-facing key gets spend caps on top - each key carries its own guardrail set on one account.
configured in the dashboard, enforced at the gateway
An allow-list with honest limits
Traffic that legitimately contains attack phrases - security training, support desks - can excuse exact phrases. The page tells you what it will not do: entries never apply to encoded text, by design.
case-insensitive substring; encoded evasions still fire
Region and model access
Restrict a key to specific models or providers, or attach the EU-only rule so requests route exclusively to models whose recorded data policy processes in the EU.
processing regions on record with source and date
A content-policy screen
The platform screen runs alongside your guardrails on every request, before routing - so the two never disagree about what left the building.
both run concurrently; refusal beats routing
AI guardrails
Best practices - the order that works
- 01
Start with visibility, not blocking
Route traffic through the gateway first and read the request log. You cannot write good rules for traffic you have never seen - and most teams discover their real risk is spend, not injection.
- 02
Give every product its own key
Guardrails attach per key, so per-product keys are the unit of policy. One key per agent or environment also makes the log tell you who did what.
- 03
Turn inspection on where users type
Customer-facing surfaces carry the injection and sensitive-data detectors; internal batch jobs usually do not need them. Enforcement where the adversary is, speed where they are not.
- 04
Excuse phrases, never patterns
When legitimate traffic trips the detector, allow-list the exact phrase - an entry is a hole exactly its own size. Widening rules to stop noise is how guardrails quietly die.
- 05
Bound the blast radius anyway
Inspection catches content; caps catch behaviour. Put a daily cap and a session cap on every key that runs unattended, so the failure you did not foresee still has a ceiling.
In the request path vs after the fact
| Final Router guardrails | Log-scanning tools | |
|---|---|---|
| When rules run | Before the provider is called | After the response - the data already left |
| Evasion handling | Base64, hex, scramble and invisible chars decoded before matching | Pattern-match on raw text, evasions pass |
| Redaction | Provider receives the redacted prompt | Original prompt was already sent |
| Scope | Per API key - different rules per product | One global setting, or none |
| Auditability | Every enforcement visible in the request log | Separate tooling, separate truth |
FAQ
Do guardrails slow my requests down?
The detectors are a local scan plus at most one allow-list read, and they run concurrently with the content-policy screen rather than after it - the request pays the slower of the two, not the sum. For most requests the added latency is negligible next to model generation time.
What evasions does the injection detector actually catch?
Base64 and hex encodings, letter-scrambled phrases and invisible-character padding are decoded or normalised before patterns are matched. A phrase disguised in any of those forms is treated exactly like the phrase in the clear - which is also why allow-list entries deliberately do not apply to encoded text.
What happens when a rule fires?
Injection and policy refusals return a clear error naming the reason; sensitive-data findings redact and let the request continue with the redacted text. Every enforcement is recorded in the request log, so 'why was this blocked' has an answer.
Can different customers on my platform have different rules?
Yes - issue each customer or product its own API key and attach the guardrail set that fits. Keys also carry their own spend caps, model restrictions and expiry, so policy and budget travel together.
Is my prompt text stored when a guardrail inspects it?
No. Inspection happens in memory as part of the request; prompt text is only ever stored if you separately opt in to request logging, which is off by default.
Rules that run before the request, not after the incident
Attach guardrails to a key, send a hostile prompt, and watch the log show exactly what was caught and why.
Related: AI spend management, LLM observability, the EU gateway, security practices.