Guardrails
Guardrails scan what people and applications send to models, and what models send back, against the tenant’s policy. They find personal data, secrets, prompt injection, toxic content and topics the tenant has banned, and either record what they found or act on it. This page explains the model behind the policy. The page where a tenant sets it is Guardrails.
What is checked
Section titled “What is checked”| Detector | What it finds |
|---|---|
| Personal data | Person names, email addresses, phone numbers, payment card numbers, IBANs and IP addresses. Recognisers for national identifiers come in optional packs a platform administrator registers for the jurisdictions you need. |
| Secrets | API keys, access tokens, passwords and similar credentials in text. |
| Prompt injection | Text that tries to override the instructions a model was given. |
| Toxicity | Abusive or harmful content. |
| Banned topics | Topics the tenant names. |
Each tenant has one policy. It decides which detectors run, whether prompts, answers or both are checked, and what happens on a finding. The thresholds and the list of personal-data types are set over the management API; the console sets everything else.
Observe, then enforce
Section titled “Observe, then enforce”A policy is in one of two modes:
- Observe: every finding is written to the audit trail, and the text passes unchanged. Nothing is blocked or rewritten. A new tenant starts here, so you can see what the detectors would do before they do it.
- Enforce: findings act. Personal data is redacted (replaced before the model or the caller sees it) or the request is blocked. Unsafe content is blocked or flagged.
A caller whose request is blocked receives HTTP 403 with the code guardrails_blocked. See Errors.
Where the policy applies
Section titled “Where the policy applies”The same policy applies on every path a model is reached by:
- API calls through the gateway, from applications and from agent runs.
- The console’s own features: the Playground, assistant chat, including share links, and knowledge queries.
Checking answers on the gateway means holding each answer until it is complete. A tenant that checks answers therefore receives streamed responses in one piece, at the end, rather than token by token. A tenant that checks only prompts streams normally. In the console’s own chat surfaces answers stream as they are written, so a finding in an answer there is recorded but cannot block or redact it.
Developer keys are checked under a code profile. Code is full of strings that look like personal data, and rewriting them breaks the code. Under the code profile the secret and prompt-injection checks always run on prompts; personal data, toxicity and banned-topic checks are off; and answers are not checked, so they stream.
When the scanner cannot answer
Section titled “When the scanner cannot answer”Guardrails are a service the platform administrator turns on. Until it is installed, nothing is scanned, and the console says so on the Guardrails page.
Once it is on, a scan that fails or times out is decided by one platform setting. Fail closed, the default, refuses the request with HTTP 503 and guardrails_unavailable: no unscanned text reaches a model. Fail open lets it through unscanned. Content the scanner cannot read at all is refused with HTTP 422 and guardrails_unscannable.
What it guarantees
Section titled “What it guarantees”- Observe changes nothing. You can turn detectors on in production and read the findings before any request is affected.
- Enforce applies before the model sees the prompt, and, on the gateway when answers are checked, before the caller sees the answer.
- Every finding is on the record, in the audit trail, in either mode. A finding records its category, the kind of entity, a score and a count, never the text that matched.
- Failure refuses by default. A broken scanner stops traffic rather than waving it through, unless your platform administrator chose otherwise.