Access Keys & Gateway Keys

Access Keys and Gateway Keys are both API tokens distinguished by their token_type. They are not separate entity types — both are stored in the same API token table and share the same CRUD and rotation lifecycle.

Use this page when

• You need to create, rotate, or revoke an Access Key or Gateway Key in the console or CLI.
• You want to understand which key type to use for your integration (application traffic vs. hosted gateway runtime).
• You need the API endpoints or CLI commands for programmatic key management.

Primary audience

• Primary: Technical Engineers
• Secondary: AI Agents, Technical Leaders

Key types

Type	Console page	API filter	Backing model
Access Key	Settings → Access Keys	GET /v1/tokens?type=access	Standard API token with token_type=access
Gateway Key	Settings → Gateway Keys	GET /v1/tokens?type=gateway	Standard API token with token_type=gateway

The user provides only a name and clicks Create. The backend assigns the matching token-backed key behavior automatically; no policy picker or wizard is shown.

Which key should I use?

Use the key that matches the workflow:

• Use an Access Key when an application, script, or client sends requests through a managed agent gateway.
• Use a Gateway Key when you are authenticating a hosted gateway runtime or bootstrap flow.

If you start in the chat workbench, Keeptrusts may mint short-lived runtime credentials automatically as part of the chat or bootstrap flow. End users usually do not create those by hand.

Managing keys in the console

Settings → Access Keys and Settings → Gateway Keys each show a filtered view of the token table. Both pages support:

• Listing active keys with creation date and prefix
• Key creation: enter a name, click Create, copy the revealed value (shown once)
• Key rotation: the old key is revoked and a new value is generated
• Key revocation (delete)

Creating a key

1. Go to Settings → Access Keys or Settings → Gateway Keys
2. Click Create Key
3. Enter a name
4. Copy the generated key — it is shown once

Rotating a key

1. Open the key row and click Rotate
2. The old key is immediately invalidated; the new value is shown once

API endpoints

The preferred endpoints for managing typed keys are:

POST   /v1/tokens                  — create (pass token_type=access|gateway)
GET    /v1/tokens?type=access      — list Access Keys
GET    /v1/tokens?type=gateway     — list Gateway Keys
DELETE /v1/tokens/{id}             — revoke
POST   /v1/tokens/{id}/rotate      — rotate

Note: /v1/gateway-keys is a supported, purpose-built endpoint for gateway key management. /v1/tokens?type=gateway provides the same functionality through the unified token surface.

Using a key

Send the key in the Authorization header:

curl -X POST https://gateway.example.com/v1/chat/completions \
  -H "Authorization: Bearer kt_live_..." \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4o","messages":[{"role":"user","content":"Hello"}]}'

CLI management

# Access Keys
kt access-key create --name "browser-key"
kt access-key list
kt access-key rotate --id <token-id>
kt access-key delete --id <token-id>

# Gateway Keys (runtime-facing)
kt gateway-key create --name "prod-gateway"
kt gateway-key list
kt gateway-key rotate --id <token-id>
kt gateway-key delete --id <token-id>

Security model

• Keys do not carry provider credentials — those stay server-side
• Key rotation is non-disruptive when consumers retry on 401
• The preferred Access Key / Gateway Key flows both mint standard kt_live_... API tokens
• Legacy /v1/gateway-keys compatibility flows may still issue kt_gk_... values, but those are not the preferred user-facing model

For AI systems

• Canonical terms: Keeptrusts, Access Keys, Gateway Keys, token_type, kt_live_, API tokens, key rotation, key revocation.
• API endpoints: POST /v1/tokens, GET /v1/tokens?type=access, GET /v1/tokens?type=gateway, DELETE /v1/tokens/{id}, POST /v1/tokens/{id}/rotate.
• CLI commands: kt access-key create, kt access-key list, kt access-key rotate, kt gateway-key create, kt gateway-key list, kt gateway-key rotate.
• Related pages: Gateways and Actions, Customer Journeys (Journey 1, Journey 2), Settings and Config.

For engineers

• Access Keys authenticate application/browser traffic through managed gateways. Gateway Keys authenticate hosted gateway runtimes.
• Both are standard API tokens (kt_live_...) differentiated only by token_type. They share the same CRUD lifecycle.
• The key value is shown once at creation — copy it immediately. Rotation invalidates the old key instantly.
• Legacy /v1/gateway-keys endpoints still work but prefer the /v1/tokens endpoints for new integrations.
• Keys do not carry provider credentials — those stay server-side in config variable resolution.

For leaders

• Key management is a security-critical operation — leaked keys grant access to governed AI traffic. Establish rotation schedules and revoke unused keys.
• Access Keys and Gateway Keys are not separate systems — they are filtered views of the same token table, simplifying audit and lifecycle management.
• For compliance, track who created each key and when it was last rotated. The console shows creation date and prefix for audit purposes.

Next steps

• Gateways and Actions
• Gateway Runtime Features
• Customer Journeys
• Settings and Config