Guardrails
Every request's prompt text is scanned for prompt-injection patterns before it reaches the model. By default the result is only reported back to you; you can ask the gateway to refuse instead, per request.
Policies#
Set the policy with the X-Ahura-Guardrail request header.
| Value | Behaviour |
|---|---|
warn | Scan, annotate the response, never refuse. The default. |
block | Scan; refuse with 400 guardrail_blocked when a critical pattern matches. Softer matches are annotated only. |
off | Do not scan. |
The scan covers system and user messages on both the chat completions and the messages endpoints. It is a static, high-precision pattern set, tuned to miss a clever attempt rather than refuse a legitimate prompt that happens to mention ignoring instructions.
Reading the result#
Every response carries X-Ahura-Guardrail:
clean: nothing matched.flagged: something matched and the request went through (policy warn, or a soft match under block).blocked: the request was refused. The body names the pattern ids.
{
"error": {
"message": "Request blocked by prompt-injection guardrail (patterns: ignore_previous)",
"type": "invalid_request_error",
"code": "guardrail_blocked",
"request_id": "…"
}
}Rolling it out#
Run with the default for a while and log the header. When you have seen how often flagged appears on real traffic and looked at what triggered it, switch the untrusted paths, such as anything that pastes user-uploaded text into a prompt, to block. Keep internal tooling on warn or off.
Something missing or wrong on this page? Tell us, and quote the page title.