64 docs indexed
Per-tenant content safety at the gateway — scan and block, redact, or log prompt injection, PII, banned keywords, and harmful content on requests and responses.
Guardrails are obleth's per-tenant content-safety policy. When a tenant has a guardrails policy, the gateway scans that tenant's request (and, optionally, response) content and blocks, redacts, or logs matches — prompt injection, PII, banned keywords, and harmful content — before the request reaches a model or the response reaches the client.
Like the other capabilities it sits beside in boons/, guardrails is
fail-open by default and runs entirely at the gateway, so it protects every
client of a tenant with no client-side changes.
Guardrails differ from the model boons in one key
way: there is no global master switch and no per-model boons grant. A
tenant's guardrails are on whenever that tenant has a policy set, and off
when it doesn't. You configure them entirely through the per-tenant policy.
guardrails_policy. Set one to
enable scanning for that tenant; clear it to disable.prompt_injection, pii,
ban_keywords) are deterministic and run in-process with no model call. The
tier-2 harm scanner calls a configured guard model to classify content.input_scanners run on the incoming request; optional
output_scanners run on the model's completion.| Scanner | Tier | Runs on | What it catches |
|---|---|---|---|
prompt_injection | 1 (deterministic) | input | Prompt-injection / jailbreak patterns |
pii | 1 (deterministic) | input, output | Personal info — SSN, email, phone, card numbers |
ban_keywords | 1 (deterministic) | input, output | A tenant-supplied keyword list (ban_keywords) |
harm | 2 (guard model) | input, output | Harmful content, classified by the configured guard_model |
The policy action decides what happens when a scanner flags content:
block — reject the request with 400 (content policy violation). The
model is never called.redact — mask the matched spans (e.g. PII) and let the request proceed
with the sanitized content.log_only — never block or modify; record an alert so you can monitor what
would have been caught. Output-side log_only scanning runs asynchronously
after the response has streamed, so it adds no latency.By default (fail_open: true) a scanner error — including a guard-model timeout
or outage — passes the content through unchanged, so a flaky scanner never takes
down a tenant. Set fail_open: false to fail closed: if a scanner can't run,
the request is rejected with 503 content policy scanner unavailable.
Open a tenant and use the Guardrails tab. Start from a preset and tune from there:
pii) on both requests and responses;
passes through on scanner error.prompt_injection) on the request before
it reaches the model or the tool loop.Set or clear a tenant's policy with PATCH /api/v1/tenants/{id}/guardrails. Send
{"policy": null} to remove it (disables guardrails for the tenant).
curl -X PATCH http://localhost:9180/api/v1/tenants/$ID/guardrails \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"policy": {
"action": "redact",
"input_scanners": ["pii", "prompt_injection"],
"output_scanners": ["pii"],
"guard_model": "qwen3-235b",
"ban_keywords": [],
"fail_open": true
}
}'
| Field | Type | Notes |
|---|---|---|
action | string | block, redact, or log_only |
input_scanners | string[] | Any of prompt_injection, pii, ban_keywords, harm |
output_scanners | string[] | Any of pii, ban_keywords, harm |
guard_model | string | null | model_name for the tier-2 harm scanner (required if harm is used) |
ban_keywords | string[] | Tenant keyword list for the ban_keywords scanner |
fail_open | boolean | true (default) passes through on scanner error; false rejects with 503 |
The tier-2
harmscanner only runs whenguard_modelis set and that model is registered. Tier-1 scanners need no model.
boon:guardrails_input
and boon:guardrails_output spans (see
Observability).harm classifications are helper-model calls, metered
against the tenant as a guardrails_boon usage record. Tier-1 scanners make no
model call and aren't billed.log_only (and flagged block/redact events) surface through the
usage ledger so you can audit what guardrails caught.Guardrails live in the same gateway engine as the model boons
and share their fail-open posture, but they are enabled per tenant (by setting
a policy), not per model (via the boons list). A model never needs to opt
in — a tenant's guardrails apply to whatever models that tenant calls.