Skip to main content

kt init

Initialize a new Keeptrusts policy project with a starter policy-config.yaml and test scaffolding.

Usage​

kt init [OPTIONS]

Options​

FlagDescription
--listList available template IDs and exit
--template <id>Use an industry template as starting point
--dir <path>Directory to initialize (default: current directory)
--forceOverwrite existing generated files
--config <path>Optional CLI config file to use when fetching templates from the API
--api-url <url>Override the Keeptrusts API URL for template fetches
--api-token <token>Override the Keeptrusts API token for template fetches
--profile <name>CLI profile to use when fetching templates (default: default)

Examples​

List Available Templates​

kt init --list

With a token and a usable templates endpoint, output contains each template's ID, name, type, and category. Without a token—or when the API response cannot be used—the command lists template IDs discovered from a nearby repository demos/ directory. A standalone installation without local demos can therefore print no rows when the API catalog is unavailable.

Default Initialization​

kt init

Creates:

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

Generated policy-config.yaml:

pack:
  name: my-policy
  version: 0.1.0
  enabled: true
  description: "Keeptrusts policy configuration"

policies:
  chain:
    - prompt-injection

policy:
  prompt-injection: {}

From Template​

Initialize with an industry template as the starting point:

kt init --template finance --dir ./finance-gateway
kt init --template healthcare-us-hipaa --dir ./hipaa-gateway
kt init --template colorado-ai-act --dir ./colorado-ai-gateway
kt init --template third-party-ai-risk --dir ./vendor-review-gateway

What to Do Next​

After kt init, follow this sequence:

cd ./finance-gateway

# 1. Review and customize the config
vim policy-config.yaml

# 2. Add a provider target and reference its credential from the environment
#    or secret store. Use a provider and model your account supports.

# 3. Validate
kt policy lint --file policy-config.yaml

# 4. Run tests
kt policy test --json

# 5. Start the gateway from the declarative config
kt gateway run \
  --listen 127.0.0.1:41002 \
  --agent docs-demo \
  --policy-config policy-config.yaml

The default scaffold contains a policy and one golden test, but no provider target. Add and validate a provider before serving model traffic. Starting a connected gateway also requires KEEPTRUSTS_API_TOKEN; that runtime credential is separate from the application token used to call the gateway.

Template loading verifies that returned starter content is YAML. kt policy lint is the schema and runtime-mode validation step; do not skip it after initialization.

If you want the broader operating model behind this sequence, read Config-First Workflow.

Next steps​