64 docs indexed

Guardrails

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.

How it works

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.

  • Per-tenant. Each tenant carries an optional guardrails_policy. Set one to enable scanning for that tenant; clear it to disable.
  • Two tiers of scanner. Tier-1 scanners (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 and output. input_scanners run on the incoming request; optional output_scanners run on the model's completion.
  • Internal keys are exempt. Gateway-owned probe keys are never scanned.

Scanners

ScannerTierRuns onWhat it catches
prompt_injection1 (deterministic)inputPrompt-injection / jailbreak patterns
pii1 (deterministic)input, outputPersonal info — SSN, email, phone, card numbers
ban_keywords1 (deterministic)input, outputA tenant-supplied keyword list (ban_keywords)
harm2 (guard model)input, outputHarmful content, classified by the configured guard_model

Actions

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.

Fail-open vs fail-closed

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.

Configuring guardrails

From the dashboard

Open a tenant and use the Guardrails tab. Start from a preset and tune from there:

  • FERPA / PII redaction — redact PII (pii) on both requests and responses; passes through on scanner error.
  • Prompt-injection defense — block (prompt_injection) on the request before it reaches the model or the tool loop.
  • Monitor only — log an alert when PII appears, never block or modify.
  • Custom — hand-pick the action, scanners, keyword list, and guard model.

Via the Management API

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
    }
  }'
FieldTypeNotes
actionstringblock, redact, or log_only
input_scannersstring[]Any of prompt_injection, pii, ban_keywords, harm
output_scannersstring[]Any of pii, ban_keywords, harm
guard_modelstring | nullmodel_name for the tier-2 harm scanner (required if harm is used)
ban_keywordsstring[]Tenant keyword list for the ban_keywords scanner
fail_openbooleantrue (default) passes through on scanner error; false rejects with 503

The tier-2 harm scanner only runs when guard_model is set and that model is registered. Tier-1 scanners need no model.

Observability and billing

  • Spans. When tracing is enabled, guardrails record boon:guardrails_input and boon:guardrails_output spans (see Observability).
  • Billing. Tier-2 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.
  • Alerts. log_only (and flagged block/redact events) surface through the usage ledger so you can audit what guardrails caught.

Relationship to model boons

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.