Skip to Content
What Is Keel

What is Keel

Keel is a permit-centric AI governance control plane with governed execution and proxy surfaces.

It sits between your application and AI providers and gives you one decision boundary for whether model work is allowed to run.

Public mental model

  • Keel evaluates policy and budget before execution.
  • On Keel-managed routes, no request reaches a provider before that decision.
  • If execution is allowed, Keel can govern it across supported providers.
  • Every governed request produces route-appropriate persisted evidence.

What Keel does

  • returns a decision record when you use POST /v1/permits
  • executes governed requests when you use /v1/execute, /v1/executions, or /v1/proxy/*
  • enforces supported policy, budget, routing, and retry controls on the documented public routes
  • records permits, executions, usage, jobs, and related evidence on documented readback surfaces
  • uses project-scoped provider credentials on Keel-managed execution routes

What Keel is not

  • not a model host
  • not an autonomous routing system
  • not just a proxy, wrapper, or logging layer

Public surface today

Keel’s documented public surface falls into four groups:

  • decision and audit routes such as POST /v1/permits and permit readback
  • governed execution routes: primary POST /v1/execute, provider-neutral POST /v1/executions, and provider-native POST /v1/proxy/*
  • async lifecycle routes such as POST /v1/jobs and GET /v1/jobs/{job_id}
  • project-scoped readback routes such as request timeline, governance events, and compliance exports

Use Public API Surface for the current endpoint index and exposure labels.

Current scope

Keel public docs cover:

  • what Keel checks and records on the public runtime routes
  • which request shapes each public route family supports
  • what buyers and developers can rely on across the current beta surface
  • the important limits, non-claims, and plan gates that shape the current product boundary

What Keel does not claim

  • fully autonomous provider choice across all routes and providers
  • universal Prompt Firewall coverage across every payload type and every provider
  • exact pre-dispatch pricing for every multimodal request shape
  • uniform replay or execution-binding guarantees across every public surface
  • cryptographic or externally verifiable guarantees for every record on every public surface
  • public support for undocumented, dashboard-only, or internal routes

Where to go next

Last updated on Edit this page on GitHub