Skip to main content
Policies are rules enforced in the gateway request path — they run after auth and budget checks, before the request is forwarded to a provider. A blocked request never reaches the provider. (The one exception is tool_allowlist, which governs agent tool calls on the /mcp/tool-call path rather than model requests — see Agentic governance.)

​
Policy types

​
Model allowlist

Restricts which models keys in the tenant can use. Requests for unlisted models return a 403. The YAML lives under routing.allowed_models:
An empty or missing list is rejected at save time — the gateway fail-opens (allows every model) on an empty allowlist, so the API blocks that shape before it can ship.

​
PII (pii)

Scans the outbound request body and replaces a fixed set of four patterns — email, phone, SSN, credit card — before forwarding. The original prompt is never sent to the provider. This type takes no configuration body; it’s a tenant-wide on/off toggle:
Redacted values are replaced with [REDACTED:email], [REDACTED:phone], etc. — see PII Redaction for the full pattern list. The request’s signed receipt records a GUARDRAIL: REDACTED check (not the original value).

​
Prompt injection detection

Detects adversarial instruction injection attempts in the user turn. action is block or warn (log but allow) — there is no severity/sensitivity setting.
On block, the response is:

​
Tool allowlist (tool_allowlist)

Restricts which tools an agent may invoke through the gateway’s /mcp/tool-call governance endpoint. Patterns are globs, under allowed_tools:
Like model_allowlist, an empty list is rejected at save time (the gateway fail-opens on an empty allowlist). Enforcement depends on the tenant’s agentic governance mode — see Agentic governance for the full lifecycle (agent identity, the three modes, and signed tool-call receipts).

​
Budget (budget)

The numeric per-key and per-user budget limits described in Budgets. Like pii, this is a tenant-wide singleton with no configurable YAML body — at most one budget policy exists per tenant.

​
Policy scope

Policies are tenant-scoped only — there is no per-key policy attachment. A policy you create applies to every key in the tenant; there’s no keyIds field and no notion of “which policies apply to this key.”

​
Enforcement audit trail

Every enforcement decision lands on the request’s signed receipt as an ALLOWLIST or GUARDRAIL check (PASS, FAIL, or REDACTED) — query it directly with GET /v1/receipts?check=ALLOWLIST or check=GUARDRAIL. See Receipts for the full check-array shape. The POLICY stage in the Console shows real per-policy hit counts sourced from ClickHouse — not placeholder data — alongside the live enforcement feed.

​
Creating a policy

​
Console

POLICY → Create policy — choose a type, fill the structured form, or switch to raw YAML for advanced config. The editor validates YAML on save and blocks invalid schemas.

​
REST API

See the full endpoint reference: POST /v1/policies — per-type YAML shapes, validation, and error responses.