Keeptrusts Docs

Keeptrusts is a config-first AI governance platform. For most teams, the primary interface is policy-config.yaml: you declare the providers, policies, limits, and audit behavior you want, and the gateway enforces that configuration on every AI request.

Use this page when

• You are new to Keeptrusts and need to orient yourself across the documentation.
• You want to choose the right audience path (engineer, leader, or AI agent) for your role.
• You need a starting point for the config-first operating model.

The console, CLI, and optional API support that lifecycle. They help you validate, distribute, observe, and review the config — but the config remains the source of truth.

If you only read one orientation page before diving in, start with Config-First Workflow. It explains the operating model we recommend for almost every Keeptrusts deployment.

Primary audience

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

Choose your audience path

AI AgentsRoute retrieval and integration work

Use the machine-oriented path to choose the right Keeptrusts sources for code generation, project setup, and integration-safe answers.

llms.txt · Source priority · IntegrationsTechnical EngineersGet from concept to running gateway

Start with the fastest engineering path for configuration, provider integration, deployment, and day-two operations.

Quickstart · Config · RuntimeTechnical LeadersEvaluate operating model and rollout fit

Use the leadership path to assess architecture, governance, cost control, compliance posture, and deployment models.

Architecture · ROI · Compliance

Start with the config workflow

ModelUnderstand the config-first workflow

See how policy-config.yaml stays central while the CLI, console, and API support validation, rollout, and operations.

Operating model · Ownership · Rollout loopWriteQuickstart a working config

Create a usable policy-config.yaml, lint it, test it, run the gateway, and send your first governed request.

Config authoring · Validation · First trafficReferenceLearn the exact schema

Use the config reference when you need the supported document shapes, field semantics, and validation rules.

Schema · Policy blocks · ProvidersRoll outVersion and deploy configs

Save validated drafts, compare versions, sync from Git, and roll the approved config out to gateways.

Configurations · Git Sync · RolloutRunInstall the gateway and serve traffic

Install kt, load your config, and expose a governed OpenAI-compatible gateway endpoint.

CLI · Gateway runtime · Compatibility

What you control from config

ProtectSafety, redaction, and compliance

Block, redact, rewrite, score, and escalate prompts and responses from one deterministic policy chain.

Policies · Templates · AuditRouteProviders, models, and fallback

Choose where traffic can go, declare data-handling constraints, and define retries or fallback in YAML.

Providers · Routing · Data policyTestValidation and policy tests

Lint every config, run tests before rollout, and treat traffic-impacting changes like reviewed code.

Linting · Test suites · CIControlBudgets, wallets, and rate limits

Control who can spend what, cap traffic, and keep usage inside approved limits.

Wallets · Rate limits · UsageGroundKnowledge and governed context

Bind curated knowledge assets so responses stay grounded, reviewable, and easier to verify.

Knowledge Base · Bindings · CitationsProveEvidence, review, and audit

Export decision trails, inspect blocked traffic, and preserve operational evidence for auditors and incident responders.

Events · Escalations · Exports

Browse by job

AuthorWrite and validate config

Use the reference, config patterns, and policy-test docs to produce a versioned config you trust.

Schema · YAML · Test casesRoll outVersion, review, and deploy changes

Use Configurations, version history, and managed rollouts to ship policy changes safely.

Versions · Rollout · DriftOperateRun the daily governance loop

Investigate decisions, review escalations, monitor spend, and export evidence from the console.

Console · Events · Escalations · ExportsTroubleshootResolve operational issues quickly

Use the public troubleshooting, evidence, and investigation workflows when the live system does not match expected policy behavior.

Troubleshooting · Events · Rollout review

Follow this order

Step 1Understand the operating model

Start with the config-first workflow so your team treats policy-config.yaml as the source of truth and uses every other surface around it.

Workflow · Ownership · Product surfaceStep 2Write a first config

Start with Quickstart so you have a working policy-config.yaml, a provider target, and an initial policy chain.

Quickstart · First config · Sample providerStep 3Roll out an approved version

Use Configurations to move the tested config onto shared gateways with version history and rollback context.

Configurations · Versions · RollbackStep 4Observe and iterate

Review live outcomes in Events, escalations, spend, and exports so the next config change is driven by evidence.

Console · Events · Escalations · Usage

Operating model

Keeptrusts runs as a gateway between your applications and upstream AI providers. The declarative config tells that gateway what to enforce, where traffic may go, which users or teams are limited, and what audit evidence to record.

Your deployment team may expose Keeptrusts as a managed hosted gateway, a self-hosted runtime, or both. The console, CLI, and chat workbench give your team operational visibility and human oversight without moving the source of truth out of config.

API is optional

Most users do not need to start with the API. Use the API reference only when you must automate a workflow that the CLI or console cannot already cover, such as custom provisioning or external orchestration.

Even in those cases, the recommended pattern is still to treat the declarative config as the canonical contract and let the API move versions of that contract around.

What these docs cover

• Declarative config: schema, policy controls, provider routing, testing, environment variables, and end-to-end examples.
• CLI and gateway runtime: bootstrap, lint, test, gateway startup, runtime inspection, and operator workflows.
• Config operations: saved versions, YAML authoring, rollout, drift review, events, escalations, exports, wallets, and audit evidence.
• Chat workbench and console: governed chat, knowledge grounding, connectors, approvals, and day-to-day review loops.
• API reference: lower-level automation support when the CLI or console is not sufficient.
• Operational troubleshooting: public guidance for incidents, evidence review, and policy rollout checks.

For AI systems

• Canonical terms: Keeptrusts, policy-config.yaml, config-first, gateway, console, CLI, control plane.
• This is the documentation root. Use it to discover entry points by audience or job.
• Priority next pages: Config-First Workflow, Quickstart, Declarative Config Reference, Install the Gateway.
• Machine-readable source list: llms.txt.

For engineers

• Start with Quickstart to produce a working policy-config.yaml and send your first governed request.
• Use Install the Gateway if you need the kt binary first.
• The console, CLI, and API are operational surfaces around the config — the config remains the source of truth.

For leaders

• Keeptrusts is a config-first platform — policy changes are reviewable, version-controlled artifacts, not hidden UI toggles.
• The platform supports local, hosted, and hosted gateway topologies. Evaluate your deployment model in Architecture and Deployment.
• Governance, spend control, and compliance evidence are built into the operating model from day one.

Next steps

• Config-First Workflow — understand the operating model
• Quickstart — write and run your first config
• Install the Gateway — get the kt binary
• Console Overview — day-to-day operational UI
• Declarative Config Reference — full config schema