Skip to main content

Getting Started with kt: Installation and Your First Gateway

The kt CLI is the shortest path into the Keeptrusts operating model. It installs as a single binary, gives you the policy authoring loop from the terminal, and starts the gateway that sits between your applications and upstream AI providers. If you can install one binary and export one provider key, you can have governed traffic flowing in minutes.

Use this page when​

  • You are installing kt for the first time and want a practical path to a working gateway.
  • You need the smallest end-to-end loop that proves Keeptrusts is intercepting AI traffic.
  • You want a getting-started guide that stays aligned with the config-first workflow instead of jumping straight to raw API calls.

Primary audience​

  • Primary: Technical Engineers and platform builders
  • Secondary: Technical Leaders, AI agents, developer enablement teams

The problem​

Most AI tooling is easy to start and hard to govern. A team can send prompts directly to a provider in a few lines of code, but the moment they need policy enforcement, routing, redaction, audit evidence, or grounded answers, they discover there is no clean operating boundary between the application and the model.

That is why the first mile matters. If getting started is too complicated, teams skip the structured path and go back to direct provider calls. If the setup path is too magical, they cannot explain what is actually running. The right onboarding experience has to be short enough for engineers to adopt and explicit enough for operators to trust.

kt solves that by keeping the workflow concrete:

  • install the binary
  • create or inspect a policy-config.yaml
  • validate the config
  • start the gateway
  • send one governed request through it

That sequence gives a team a real runtime boundary on day one rather than a demo that will have to be rebuilt later.

The solution​

The supported installation paths are straightforward. On macOS and Linux, you can install from the Keeptrusts binary release. You can also build from source if your environment requires tighter supply-chain control, or run the CLI in Docker when you want to containerize the workflow.

Once installed, the CLI gives you the basic bootstrap commands you need right away: kt --version, kt init, kt policy lint, kt policy test, and kt gateway run. That is enough to move from an empty working directory to a gateway handling governed OpenAI-compatible traffic.

Implementation​

Start with the binary install and verify the CLI is present:

curl -fsSL https://dl.keeptrusts.com/releases/latest/kt-macos-universal.tar.gz \
  | sudo tar xz -C /usr/local/bin kt

kt --version

Then create the smallest workable project:

kt init
export OPENAI_API_KEY="sk-live-team-gateway-key"
kt policy lint --file policy-config.yaml
kt policy test --json

kt init gives you a starter config and a starter test under tests/. That matters because Keeptrusts is designed around a config-first workflow, not a one-off runtime command. The gateway should start from the same config you lint and test.

When you are ready to run the gateway, keep the config simple enough to understand:

pack:
  name: first-gateway
  version: 0.1.0
  enabled: true

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

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

policy:
  pii-detector:
    action: redact

  audit-logger:
    retention_days: 30

That config is enough to show the product shape clearly. One provider target is defined declaratively. Prompt injection can be evaluated before the request reaches the provider. PII can be redacted. Audit events can be retained.

Now start the runtime:

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

From a second terminal, send a request through the gateway instead of the provider directly:

curl http://localhost:41002/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.4-mini-mini",
    "messages": [
      {"role": "user", "content": "What is AI governance?"}
    ]
  }'

At that point the important milestone is already achieved. Your application-facing endpoint is now the Keeptrusts gateway, not the upstream model provider. The gateway owns policy evaluation, logging, and routing decisions.

If you want a slightly safer first-run workflow, add kt doctor after installation to verify environment and connectivity before you begin changing configs. That helps when the problem is not your YAML, but your local setup.

Results and impact​

The first practical outcome is speed to a governed runtime. Engineers can get from installation to a live gateway quickly without skipping the contract that will matter in production.

The second outcome is better habits. Because the startup path already includes linting and testing, teams begin with the right operational loop instead of bolting it on later.

The third outcome is portability. A validated policy-config.yaml can move from a laptop to a CI job to a managed rollout with much less translation than teams usually expect. The same artifact defines provider targets, enforcement chain, and runtime behavior.

That is the real value of getting started with kt instead of hand-wiring direct provider calls. You are not just launching a process. You are establishing the control surface that future policy, grounded knowledge, and rollout automation will use.

Key takeaways​

  • kt is designed to start with a config-first loop, not a one-off runtime command.
  • kt init, kt policy lint, and kt policy test are the fastest way to establish good habits before live traffic.
  • kt gateway run turns Keeptrusts into the application-facing AI endpoint.
  • Keeping provider credentials in secret_key_ref.env preserves portable YAML and keeps secrets out of config files.
  • Your first gateway should be simple enough to reason about, then expanded once the runtime loop is proven.

Next steps​