Configuration & Policy Overview
This section shows how declarative config controls gateway behavior. Use it to select policy types and set their sequence in policies.chain. It also shows runtime behavior.
Start here
| Your task | Start with |
|---|---|
| Understand the supported top-level schema | Declarative Config Reference |
| Browse supported controls before selecting one | Policy Controls Catalog |
| Define provider targets, routing, or fallback | Providers Configuration and data-routing-policy |
| Add tests before rollout | Config Testing and verdictan policy test |
| Protect sensitive or controlled data | pii-detector and dlp-filter |
| Defend the input boundary | prompt-injection |
Follow this sequence
- Read the Declarative Config Reference to select the correct document shape.
- Select policy types from the Policy Controls Catalog.
- Add them to
policies.chainand tune each block inpolicy.<kind>. - Validate the config with lint and tests before rollout.
- Add the audit marker.
- Verify request results with
verdictan eventsor the Events API. - Add History only when capture is enabled and stored session context is necessary.
How policies work
Primary policy groups
Request and routing controls
| Policy type | Purpose |
|---|---|
prompt-injection | Block prompt-injection and jailbreak signals before upstream calls |
pii-detector | Detect sensitive identifiers and redact or block request content |
dlp-filter | Apply broader pattern-based filtering for sensitive or proprietary data |
rbac | Apply role, identity, and sensitivity-based access rules |
agent-firewall | Limit agent tool use and dangerous action classes |
data-routing-policy | Filter provider targets by retention or training metadata |
Output controls
| Policy type | Purpose |
|---|---|
quality-scorer | Score output quality and block or replace failed output |
human-oversight | Return an escalated result and do not deliver output |
citation-verifier | Verify groundedness against context |
Audit and evidence
| Policy type | Purpose |
|---|---|
audit-logger | Emit an allow-only audit marker. Configure retention and storage through their owning workflows. |
Example configuration
pack:
name: "my-project"
version: "0.1.0"
enabled: true
policies:
chain:
- audit-logger
- prompt-injection
- pii-detector
- quality-scorer
policy:
prompt-injection:
attack_patterns:
- "ignore.*previous.*instructions"
- "forget.*system.*prompt"
encoding:
decode_base64: true
normalize_unicode: true
detect_homoglyphs: true
boundaries:
enforce_delimiters: true
reject_fake_boundaries: true
response:
action: block
pii-detector:
action: redact
pci_mode: true
quality-scorer:
assertions:
- type: word-count
config:
min: 20
thresholds:
min_aggregate: 0.7
audit-logger: {}
Key rules
- Chain sequence: Policies run in the sequence in
policies.chain. - First block: After the gateway blocks a turn, subsequent policies do not run for that stage.
- Audit marker position: Put
audit-loggerbefore blocking controls when each evaluated request must contain the marker. - Redaction and buffering: Some policies redact request text and also buffer and examine output.
- Phase limits:
human-oversightruns only on output.language-validatorenforces input checks only.
See the Declarative Config Reference for the complete schema and the Policy Controls Catalog for the inventory of supported controls.
Next steps
- Declarative Config Reference — Full config schema
- Policy Controls Catalog — Browse policy types and starter snippets
- Config-First Workflow — Operating model for policy deployment
- Config Testing — validate the specified chain before rollout