Settings

Settings is where customers verify identity context, manage Git access, adjust account-backed presentation preferences, review console diagnostics, and open related work such as Inbox, Usage, Billing, and Evidence exports. Gateway runtime verification now lives under Gateways.

Use this page when

• You need to verify your organization identity context (org ID, project ID, role) in the console.
• You want to configure Git access credentials for repository-backed configuration imports.
• You need to manage stored secrets used by gateway secret_key_ref references.
• You are looking for diagnostics, preferences, or links to Inbox, Usage, Billing, and Evidence exports.

Primary audience

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

Workflow map

Organization section

The Organization section shows the current identity context from the control plane:

• Org ID.
• Org name.
• Project ID.
• Role.

This is the quickest way to confirm you are operating in the scope you expected.

Preferences section

Customers can currently change:

• Date format.
• Timezone display.
• Language.

These preferences affect readability rather than runtime behavior.

They are stored in account preferences on the control plane so they follow the user across browsers, devices, and future sign-ins.

Related work links

The Settings sidebar also provides direct links to:

• Inbox for notification follow-up.
• Usage for spend review.
• Evidence exports for audit and incident handoff.

Git access section

Settings also stores Git provider credentials used by the Configurations page for repository-backed imports.

Customers can review or update:

• Provider.
• Username.
• Access token.

These credentials support configuration imports. They do not change the config currently running on any gateway.

Operational notes:

• The token is stored server-side and is not shown back to the browser after save.
• The page shows whether a token is currently stored and when the credentials were last updated.
• Secrets and config variables prepared here are available to the Configurations workflow through secret_key_ref.

Diagnostics section

Diagnostics exposes:

• Console version.
• Masked API URL.

Verifying identity via the API

cURL

# Check current identity context
curl https://api.keeptrusts.com/v1/whoami \
  -H "Authorization: Bearer $KEEPTRUSTS_API_TOKEN"

Python

import httpx

headers = {"Authorization": f"Bearer {api_key}"}
base = "https://api.keeptrusts.com"

# Check current identity context
whoami = httpx.get(f"{base}/v1/whoami", headers=headers).json()
print(f"Org: {whoami['org_name']} | Role: {whoami['role']}")

Node.js

const headers = { Authorization: `Bearer ${apiKey}` };
const base = "https://api.keeptrusts.com";

// Check current identity context
const whoami = await fetch(`${base}/v1/whoami`, { headers }).then(r => r.json());
console.log(`Org: ${whoami.org_name} | Role: ${whoami.role}`);

Secrets

Manage secrets used by gateway configurations from Settings → Security & Assurance → Secrets (/settings/secrets).

Secrets let you store API keys and other sensitive values in the Keeptrusts API rather than relying on environment variables on each gateway host. Provider targets reference stored secrets using secret_key_ref in their YAML config:

pack:
  name: settings-and-gateway-config-providers-1
  version: 1.0.0
  enabled: true
providers:
  targets:
  - id: openai-prod
    provider: openai
    secret_key_ref:
      store: OPENAI_API_KEY
policies:
  chain:
  - audit-logger
policy:
  audit-logger:
    immutable: true
    retention_days: 365
    log_all_access: true

The gateway resolves references at startup through the machine config-variable resolution endpoint exposed by the control plane.

Secrets are encrypted at rest (AES-GCM-SIV). Secret values are never shown in list views.

Scopes

Scope	Description
org	Available to all gateways in the organization
team	Scoped to a specific team
user	Scoped to the creating user

Required permissions

• config_vars:read — list and view secrets
• config_vars:write — create, update, and delete secrets
• config_vars:resolve — batch-resolve secret values (used by gateways)

Where gateway config verification moved

Use Gateways and the gateway-specific Actions page when you need to verify runtime behavior. That page shows:

• Local source-of-truth metadata for the gateway-host config path.
• Running gateway metadata such as digest, policy chain, upstream, and tracing state.
• Current gateway config when the gateway is active.
• Last active gateway config when the gateway is inactive.

Settings remains the right place to confirm scope and credentials before you inspect a gateway, but it is no longer the surface for runtime config drift checks. Use the Configurations and Gateways pages for runtime state rather than platform-admin API examples.

For AI systems

• Canonical terms: Keeptrusts, Settings, organization context, Git access, secrets, secret_key_ref, config variables, preferences, diagnostics.
• Console surfaces: Settings → Organization, Settings → Preferences, Settings → Git Access, Settings → Security & Assurance → Secrets, Settings → Diagnostics.
• API endpoints: GET /v1/whoami, POST /v1/config-vars, GET /v1/config-vars.
• Config names: secret_key_ref.store, secret_key_ref.env, config_vars:read, config_vars:write, config_vars:resolve.
• Best next pages: Configurations, Create Configuration, Gateways and Actions, Security Settings.

For engineers

• Use GET /v1/whoami to programmatically verify which org and role your token authenticates as.
• Secrets created here are encrypted at rest (AES-GCM-SIV) and resolved by the gateway at startup via the machine config-variable endpoint.
• Required permissions for secrets: config_vars:read (list), config_vars:write (create/update/delete), config_vars:resolve (gateway batch resolution).

For leaders

• The Organization section confirms the current operating scope — verify this matches the intended environment before reviewing events or making changes.
• Secrets management (Settings → Secrets) centralizes provider credentials so individual gateway hosts never store plaintext keys locally.
• Preferences (timezone, date format, language) are account-level and follow the user across sessions — no per-machine configuration needed.

Next steps

• Create Configuration — build, validate, and save a configuration draft
• Configurations — manage config versions and rollout
• Gateways and Actions — verify runtime config and gateway health
• Security Settings — MFA, passkeys, and route entitlements
• Members, Teams & Roles — manage team access and permissions