Skip to Content

Keel Docs

Control your AI before it runs. Hard limits, policy, and tamper-evident audit — enforced before any request executes.

Keel is the AI control plane for governed execution. It sits between your application and AI providers, evaluates policy and budget before governed execution, and records tamper-evident audit evidence on the documented public surfaces.

On Keel-managed routes, no request reaches a provider before passing the decision boundary.

Route guarantees are not identical: permit-first is still decision-only plus later caller-reported closeout, while Keel-managed routes own execution directly.

Public mental model

  • decision before execution
  • execution only if permitted
  • evidence always recorded
  • one governance boundary across supported providers

What Keel covers

  • permit-first decisions with POST /v1/permits
  • governed execution with primary runtime POST /v1/execute, provider-neutral POST /v1/executions, and provider-native /v1/proxy/*
  • project-scoped usage, audit, and evidence readback on documented public surfaces
  1. Read Overview to choose the right path through the docs.
  2. Read What is Keel to understand the product boundary and active public surfaces.
  3. Run Quickstart to get a governed request through the stack.
  4. Use Architecture and API Reference to understand the runtime surface.
  5. Review Security, Threat Model, and Known Limits before production rollout.

API reference

The API reference section now includes authored docs for the first public developer-facing routes. Start with API Reference, then use Execute, Executions, Permits, Proxy Execution, Idempotency, and Errors.

Last updated on Edit this page on GitHub