Skip to main content

Configurations

Configurations is the console workflow for versioned policy management. Use it to edit YAML, compare saved versions, roll changes out to gateways, and verify what is running.

What the page does​

Configurations combines three things in one workflow:

  • A searchable inventory of saved configurations
  • A YAML editor with inline validation and structural guidance
  • Review and rollout steps that let you save or deploy the current draft

Workflow map​

Typical workflow​

  1. Open Configurations and find the target configuration.
  2. Review the saved version, recent change detail, and rollout target.
  3. Edit YAML or import an existing policy-config.yaml.
  4. Review validation findings before you save or deploy.
  5. Save a new version with a clear change detail.
  6. Roll the version out to the intended gateway or gateways.
  7. Verify runtime state in Gateways, query representative requests with kt events tail --since 10m --json or GET /v1/events?since=10m, and inspect any affected Inbox review work. Use History for session context only when conversation capture is enabled.

Import existing YAML​

Use Import Configuration when you already have a policy-config.yaml file.

  1. Open the create flow.
  2. Choose Import Configuration.
  3. Select the file from your machine.
  4. Review the imported YAML before you save or deploy.

Referencing secrets​

Use secret_key_ref inside the configuration instead of placing secrets directly in YAML.

Environment-backed secret reference:

secret_key_ref:
  env: KEEPTRUSTS_OPENAI_API_KEY

Store-backed secret reference:

secret_key_ref:
  store: KEEPTRUSTS_OPENAI_API_KEY

Create a stored secret from an environment variable:

kt secret create \
  --name KEEPTRUSTS_OPENAI_API_KEY \
  --env-var KEEPTRUSTS_OPENAI_API_KEY

Use env when the credential is supplied directly to the local gateway process. Use store when the runtime should resolve the value from Keeptrusts-managed secret storage.

The names are operator-defined. Prefer a KEEPTRUSTS_<PROVIDER>_* prefix so a credential is not confused with a provider SDK credential consumed directly by application code.

What to verify before rollout​

Confirm all of the following:

  • The YAML reflects the intended routing and policy chain.
  • The change detail is specific enough for later review.
  • Validation findings are understood before you deploy.
  • The selected rollout target matches the gateway or environment you intend to change.

What to verify after rollout​

After rollout, verify in product surfaces rather than assuming success from the save action alone.

Check:

  • Gateways for runtime health and the version that is currently applied
  • kt events tail or GET /v1/events?since=10m for representative governed requests and their request IDs
  • History for captured session context when conversation capture is enabled
  • Inbox if the change is expected to raise or reduce human-review volume
  • Trail when you need audit chronology or exportable evidence of the rollout or follow-up activity

Bulk actions​

The configurations list supports Delete selected configurations as a bulk inventory action. It does not expose bulk rollback. Use deletion carefully and verify the running state afterward.

Next steps​