Tutorial: Using Policy Config Templates

This tutorial shows the current Keeptrusts template workflow. The CLI discovers template IDs with kt init --list, scaffolds a starter config with kt init --template <id>, and then expects you to finish the configuration for your environment before linting, testing, and running the gateway.

Use this page when

You want to bootstrap a new policy configuration from the built-in template catalog.
You need the current kt commands for listing templates, initializing one, and validating the result.
You want to turn a template-derived starter into a runnable policy-config.yaml.

Primary audience

Primary: Platform engineers bootstrapping new gateway configurations quickly
Secondary: Technical leaders standardising policy baselines across teams; compliance reviewers checking starter coverage

Prerequisites

kt CLI installed (first-run tutorial)
A checkout that includes the local demos/ catalog, or access to a Keeptrusts API session that exposes templates
A provider credential such as OPENAI_API_KEY

Step 1: List Available Template IDs

View the currently available template IDs:

kt init --list

Typical output:

agent-firewall
automotive
china-export-controls
consumer
critical-infrastructure
defense-eu
defense-us
education
eu-ai-act
finance
government
healthcare
healthcare-eu-gdpr
healthcare-us-hipaa
...
zero-data-retention

Use the ID from this list with --template.

Step 2: Initialize a Starter Config

Create a working directory from the finance starter:

kt init --template finance --dir ./finance-gateway
cd ./finance-gateway

This writes:

./
├── policy-config.yaml
└── tests/
    └── blocks_obvious_injection.json

Step 3: Inspect the Generated Starter

The generated file is a starter config, not a complete environment-specific deployment. For example, the finance starter focuses on the policy chain:

pack:
  id: "cfg_e2e_finance"
  name: "e2e-finance"
  version: "0.1.0"
  enabled: true
  author: "local"
  description: "e2e finance demo"

policies:
  chain: ["dlp-filter", "pii-detector", "financial-compliance", "quality-scorer"]

policy:
  dlp-filter:
    blocked_terms:
      - "insider trading"
      - "earnings before announcement"
    action: block
  pii-detector:
    action: redact
    pci_mode: true

Many starters intentionally focus on policy behavior. Before you run the gateway, add the provider targets, model selection, and secret references that match your environment.

Step 4: Add Provider Targets and Secrets

Add a provider block to policy-config.yaml using the canonical secret_key_ref object form:

providers:
  targets:
    - id: openai-primary
      provider: openai
      model: gpt-4o-mini
      base_url: https://api.openai.com
      secret_key_ref:
        env: OPENAI_API_KEY

For hosted gateways, use a config-variable reference instead:

providers:
  targets:
    - id: openai-primary
      provider: openai
      model: gpt-4o-mini
      base_url: https://api.openai.com
      secret_key_ref:
        store: OPENAI_API_KEY

Step 5: Validate Locally

Export the secret your config expects, lint the file, and run the generated pack test:

export OPENAI_API_KEY="sk-your-openai-key"

kt policy lint --file policy-config.yaml
kt policy test --json

Notes:

kt policy lint uses --file, not --config.
kt policy test runs from the current pack directory; it does not take a policy-config path flag.

Step 6: Run the Gateway

Start the gateway from the validated config:

kt gateway run \
  --listen 0.0.0.0:41002 \
  --policy-config policy-config.yaml

The current gateway CLI uses --listen for host and port together. Use --policy-config for one or more declarative config files.

The CLI does not provide a dedicated template-repository workflow. If your team curates its own starters, store the resulting YAML in Git like any other config-as-code asset:

ai-policies/
├── templates/
│   ├── finance.yaml
│   ├── healthcare-us-hipaa.yaml
│   └── zero-data-retention.yaml
└── teams/
    └── payments/
        └── policy-config.yaml

Teammates can then copy or adapt those checked-in YAML files directly:

cp templates/finance.yaml ./policy-config.yaml
kt policy lint --file policy-config.yaml
kt policy test --json

Step 8: Validate Template Files in CI

Add a simple validation script for template YAML stored in your repo:

#!/usr/bin/env bash
set -euo pipefail
shopt -s nullglob globstar

EXIT_CODE=0

for template in templates/**/*.yaml; do
  echo "Validating $template..."
  if kt policy lint --file "$template"; then
    echo "  ok"
  else
    echo "  invalid"
    EXIT_CODE=1
  fi
done

exit $EXIT_CODE

Run it with:

chmod +x scripts/validate-templates.sh
./scripts/validate-templates.sh

For AI systems

Canonical terms: Keeptrusts templates, kt init --list, kt init --template <id>, policy-config.yaml, starter config, policy chain.
Current CLI commands: kt init --list, kt init --template <id> --dir <path>, kt policy lint --file <path>, kt policy test --json, kt gateway run --listen <host:port> --policy-config <path>.
Example starter IDs: finance, healthcare-us-hipaa, defense-us, eu-ai-act, agent-firewall, zero-data-retention.
Best next pages: Config-First Workflow, kt init, Declarative Config Reference.

For engineers

Start with kt init --list, not kt init --list-templates.
Expect starter configs to give you policy intent first; add provider targets and secret_key_ref values before treating them as runnable.
Validate with kt policy lint --file and kt policy test --json before you start the gateway.
Keep curated template-derived YAML in Git; there is no supported kt init --from-git, --template-repo, or --interactive flow in the current CLI.

For leaders

Templates reduce time-to-first-policy by giving teams a governed starting point instead of a blank file.
The starter still needs environment-specific provider routing and secret references before rollout.
Treat template-derived configs as versioned assets in Git so review, CI validation, and promotion stay auditable.

Next steps

Config-First Workflow — the broader authoring and rollout model
kt init — exact CLI reference for starter generation
kt gateway run — current runtime flags and gateway patterns
Declarative Config Reference — full schema reference

Use this page when​

Primary audience​

Prerequisites​

Step 1: List Available Template IDs​

Step 2: Initialize a Starter Config​

Step 3: Inspect the Generated Starter​

Step 4: Add Provider Targets and Secrets​

Step 5: Validate Locally​

Step 6: Run the Gateway​

Step 7: Share Template-Derived Configs Through Git​

Step 8: Validate Template Files in CI​

For AI systems​

For engineers​

For leaders​

Next steps​