Skip to main content

Scripting Keeptrusts: 10 Automation Recipes for DevOps

The value of the Keeptrusts CLI is not just that it exposes platform actions from a terminal. It is that the commands are composable enough to become operational building blocks. Once you stop thinking of kt as an interactive tool and start thinking of it as a scriptable control surface, routine governance work gets much easier to standardize.

Use this page when​

  • You want repeatable shell recipes for validation, rollout, monitoring, and evidence export.
  • You need small automation patterns instead of one large platform script.
  • You are building runbooks or CI jobs around the Keeptrusts CLI and API.

Primary audience​

  • Primary: DevOps and platform engineers
  • Secondary: Technical Leaders who own release and incident workflows

The problem​

Most operational work around AI governance is repetitive. Validate the config. Check whether the gateway is healthy. Tail recent decisions. Push a reviewed policy version. Export evidence after an incident. Confirm a staging rollout before promoting to production.

If each operator does those tasks manually, the workflow becomes inconsistent. If the same steps are wrapped in giant bespoke automation, the workflow becomes hard to maintain. The better approach is a middle ground: small, reliable recipes that can be composed into CI jobs, cron tasks, or incident scripts.

Keeptrusts already exposes the right primitives. The missing part for many teams is a practical set of shell patterns they can adopt immediately.

The solution​

Use focused recipes that do one operational job well. The recipes below are intentionally small. They are meant to be copied into pipeline steps, runbooks, or local shell scripts with minimal adaptation.

Implementation​

1. Lint the active policy config​

kt policy lint --file policy-config.yaml

Use this as the cheapest structural gate before any rollout.

2. Run behavior tests before merge​

kt policy test --json

This is the pipeline-friendly command for proving expected verdicts instead of only valid YAML.

3. Mint a scoped token for automation​

kt auth token create --name nightly-governance --scope team --role-id role_configurations_writer

Store the emitted secret in your CI secret store immediately and use KEEPTRUSTS_API_TOKEN in non-interactive jobs.

4. Check resolved configuration before a deploy​

kt config show --json --file environments/staging/policy-config.yaml

Run this when you need proof of which API URL, profile, and token presence the CLI actually resolved.

5. Fail fast on environment health problems​

kt doctor --config environments/staging/policy-config.yaml --profile staging --json

This works well as a preflight step in any deploy or smoke-test script.

6. Validate gateway readiness without starting it blindly​

kt gateway check --config policy-config.yaml --verbose

This dry-run pattern is useful when you want provider resolution and chain visibility before touching the running process.

7. Push a reviewed config to a target gateway​

kt policy push --file policy-config.yaml --gateway-id staging

Use this when your pipeline promotes a tested config to a named environment.

8. Promote from staging to production​

kt policy deploy \
  --file policy-config.yaml \
  --source-gateway-id staging \
  --target-gateway-id production

This keeps staged promotion explicit instead of relying on a manual console step every time.

9. Tail blocked decisions after a rollout​

kt events tail --since 10m --verdict blocked --json | \
  jq '.[] | {timestamp, id, reason_code, provider, model, config_version}'

This is a strong post-deploy verification recipe because it narrows directly to the most sensitive outcome.

10. Export evidence for review or archival​

kt events export --since 24h --format json --output keeptrusts-events-24h.json

Use this after an incident, change review, or compliance check when you need a durable artifact.

The reason these recipes work well together is that they map to the full lifecycle.

Recipes 1 and 2 validate. Recipes 3 through 6 establish safe operational context. Recipes 7 and 8 deploy. Recipes 9 and 10 verify and preserve evidence.

That makes them easy to compose into larger flows. A nightly drift job might run recipes 4, 5, and 9. A release pipeline might run 1, 2, 5, 7, and 9. An incident script might skip deployment entirely and jump straight to 5, 9, and 10.

You can also wrap several of them into a single shell function when you need a standard release entry point:

release_keeptrusts() {
  local gateway_id="$1"
  kt policy lint --file policy-config.yaml
  kt policy test --json
  kt doctor --json
  kt policy push --file policy-config.yaml --gateway-id "$gateway_id"
  kt events tail --since 5m --limit 10 --json
}

That kind of wrapper is most useful when multiple teams share the same rollout model. It does not hide the underlying commands. It just enforces the right order.

The main thing to avoid is building one opaque automation script that combines every possible environment, deployment mode, and incident action. Small recipes age better because each one has a clear responsibility and a clear failure boundary.

Results and impact​

Teams that standardize on small Keeptrusts automation recipes usually see fewer rollout mistakes and faster incident response. Operators do less improvisation, which means fewer surprises in production.

The other benefit is portability. The same commands work in local shell scripts, CI runners, and runbooks. That consistency matters because it reduces the difference between how a team practices governance changes and how it actually executes them under pressure.

Key takeaways​

  • The Keeptrusts CLI is most valuable when you treat commands as composable automation primitives.
  • Small, focused recipes are easier to reuse and maintain than one large all-purpose script.
  • Validation, deployment, and evidence collection can all be expressed with a short set of CLI commands.
  • kt doctor, kt policy lint, kt policy test, kt policy push, and kt events tail cover most day-to-day DevOps needs.
  • Standardizing recipe order is often more important than adding new automation features.

Next steps​