Configuration & Policy Overview

This section explains how Keeptrusts declarative config turns policy controls into a working gateway contract. Use it to decide which policy kinds you need, how they fit into policies.chain, and how the resulting config behaves at runtime.

Use this page when

• You are starting to configure policies and need to understand how the policy system works.
• You need to choose which policy kinds to add to your policies.chain.
• You want an overview of input-phase, output-phase, and audit controls before diving into individual policy docs.

For the broader product operating model, read Config-First Workflow before diving into individual controls.

Primary audience

• Primary: AI Agents, Technical Engineers
• Secondary: Technical Leaders

Use this section when

• Author or review policy-config.yaml
• Stop unsafe, non-compliant, or high-risk traffic before it reaches an upstream model.
• Constrain routing based on retention, training, or regulatory requirements.
• Score, block, or escalate outputs before they reach users.
• Attach audit metadata so investigations and reviews have evidence instead of guesswork.

Start here

If you need to...	Start with
Understand the supported top-level schema	Declarative Config Reference
Browse every supported control before choosing one	Policy Controls Catalog
Define provider targets, routing, or fallback	Providers Configuration and data-routing-policy
Add tests before rollout	Config Testing and kt policy test
Protect sensitive or regulated data	pii-detector and hipaa-phi-detector
Detect jailbreaks or prompt injection	prompt-injection

Follow this order

1. Start with the Declarative Config Reference so the document shape is correct.
2. Pick the policy kinds you need from the Policy Controls Catalog.
3. Add them to policies.chain and tune each block under policy.<kind>.
4. Validate the config with linting and tests before rollout.
5. Add audit coverage early so the result is reviewable after deployment.

How Policies Work

1. Input policies run on the user's request before it reaches the AI provider
2. Output policies run on the provider's response before it reaches the user
3. Audit policies attach metadata and logging at any phase

Policy Categories

Input & Tool-Phase Controls

Policy Kind	Purpose
prompt-injection	Detect jailbreak and prompt-injection attacks
pii-detector	Detect and redact personally identifiable information
hipaa-phi-detector	Detect HIPAA-regulated protected health information
agent-firewall	Allow/deny tools, enforce rate and transaction limits
rbac	Role- and identity-based access control
dlp-filter	Data loss prevention pattern matching
safety-filter	Block or escalate unsafe content
itar-ear-filter	Detect export-controlled ITAR/EAR terms
entity-list-filter	Match restricted or sanctioned entities
cjis-mode	Enforce CJIS-style input constraints
data-routing-policy	Filter providers by retention and training metadata

Output-Phase Controls

Policy Kind	Purpose
quality-scorer	Enforce quality thresholds on responses
human-oversight	Escalate responses for human review
citation-verifier	Verify response groundedness against context
financial-compliance	Finance-oriented compliance enforcement
healthcare-compliance	Medical pattern blocking and disclaimers
mnpi-filter	Detect material non-public information
bias-monitor	Detect bias and fairness patterns

Audit Controls

Policy Kind	Purpose
audit-logger	Attach audit metadata for all decisions

Declarative Configuration

Policies are defined in policy-config.yaml:

pack:
  name: "my-project"
  version: "0.1.0"
  enabled: true

policies:
  chain:
    - prompt-injection
    - pii-detector
    - quality-scorer
    - audit-logger

policy:
  prompt-injection:
    embedding_threshold: 0.8
    response:
      action: "block"

  pii-detector:
    action: "redact"
    pci_mode: true

  quality-scorer:
    thresholds:
      min_aggregate: 0.7
    assertions:
      - type: "llm-rubric"
        config:
          rubric: "The answer should be accurate and grounded in evidence."
        threshold: 0.8

  audit-logger:
    retention_days: 365

The config file is the primary user interface. The console, CLI, and optional API all work with versions of this same document rather than replacing it.

Config deep dives

Use the deep-dive guides when you need exact YAML structure instead of policy concepts:

• Declarative Config Reference for the top-level document model
• Providers Configuration for routing, retries, fallback, and target metadata
• Conditional Chains for when, stage, parallel, and targeting
• Quality Assertions for scorer assertions, benchmarks, weights, and thresholds
• Compliance Policies for GDPR, EU AI Act, CJIS, export controls, and regulated-domain compositions
• End-to-End Scenarios for full working examples

Key Rules

• Chain order matters — policies execute in the order listed in policies.chain
• Conditional entries are supported — policies.chain can contain plain policy kinds or conditional objects with when, stage, parallel, and targeting
• First blocking verdict wins — if prompt-injection returns block, later policies don't run
• Strict validation — unknown keys or policy kinds are rejected at lint time
• Two document shapes — full config (with pack) or single-policy config (for testing)

See the Declarative Config Reference for the complete schema specification and the Policy Controls Catalog for the full inventory of supported controls.

For AI systems

• Canonical terms: Keeptrusts, policies, policy-config.yaml, policies.chain, input policies, output policies, audit policies, verdict, block, redact, allow, escalate
• Config/command names: policies.chain, policy phases (input/output/audit), verdicts (allow/block/redact/escalate), policy.<kind> blocks
• Best next pages: Declarative Config Reference, Policy Controls Catalog, Config-First Workflow

For engineers

• Prerequisites: The kt CLI installed. A blank or starter policy-config.yaml. Familiarity with your compliance requirements.
• Validation: Follow the "Start here" table to find the right reference page. Use kt policy lint to validate your config as you build it.
• Key commands: kt policy lint, kt gateway run, kt policy test

For leaders

• Governance: This overview maps the full policy surface. Use it to verify that your required compliance controls (data protection, content safety, access control, audit) are represented in your policy chain.
• Cost: Each policy in the chain adds per-request processing. Start with essential controls and expand based on regulatory requirements and risk appetite.
• Rollout: Follow the recommended order: schema validation → policy selection → chain composition → testing → audit → deployment.

Next steps

• Declarative Config Reference — Full config schema
• Policy Controls Catalog — Browse all policy kinds
• Config-First Workflow — Operating model for policy deployment
• Config Scenarios — Complete example configurations