Overview

Keel sits between your application and AI providers so you can decide once, execute through controlled surfaces, and keep evidence attached to the request.

Keel in one minute

• Keel is a permit-centric AI governance control plane with governed execution and proxy surfaces.
• POST /v1/permits is the canonical public decision seam. POST /v1/execute is the primary public runtime surface. POST /v1/executions is the underlying provider-neutral execution contract.
• On Keel-managed routes, denied requests do not reach a provider.
• Every governed request produces route-appropriate persisted evidence.

Integration patterns

Most teams start with the SDK provider wrappers — change one import line and every AI call is automatically governed. The wrappers handle permits, budget enforcement, execution, and usage reporting transparently.

If you are choosing raw API routes, use this hierarchy:

• POST /v1/permits for decision-first control when your app owns the provider call
• POST /v1/execute as the primary public runtime surface for provider-shaped input with normalized output
• POST /v1/executions when you want the provider-neutral request contract
• POST /v1/proxy/* when provider-native payloads and responses matter more than normalization

Use permit-first when your application wants the decision and will execute the provider call itself. Use the execution routes when Keel should enforce policy and call the provider in the same request path.

Permits and executions

Execution routes (/v1/executions, /v1/execute, /v1/proxy/*) automatically evaluate permits as part of the request — you do not need to call /v1/permits first. Call /v1/permits separately only when your application owns the provider call: use it to get a policy decision, then execute against the provider directly using that permit.

Which endpoint to use:

Need Keel to call the provider?
  Yes → Need the raw provider response?
          Yes → /v1/proxy/*
          No  → Already have a provider-shaped payload?
                  Yes → /v1/execute
                  No  → /v1/executions
  No  → /v1/permits

Public request flow

Across the public routes, Keel presents one product contract:

• Decision Boundary: Keel authenticates the project and evaluates the governed request before provider execution.
• Execution: if the route is Keel-managed and the request is allowed, Keel executes it against the selected provider.
• Evidence: Keel records the decision outcome and route-appropriate execution or usage evidence.

What changes by route is the request contract and response shape, not the product boundary:

• /v1/permits returns a decision record and leaves provider execution to your app.
• /v1/executions accepts one provider-neutral request shape and returns normalized output.
• /v1/execute accepts provider-shaped input and still returns normalized output.
• /v1/proxy/* preserves provider-native request and response semantics.

What Keel guarantees today

• A denied Keel-managed execution request does not reach the provider.
• Tenant isolation is enforced at both the database and application layers across the decision and evidence path.
• Keel offers an optional external accounting-durability mode that checkpoints accounting envelopes before provider dispatch.
• Permit-first closeout requires verification material that proves execution; the verification track attaches receipt evidence on the permit-first path.
• Missing permit-first closeout is recorded explicitly as missing_usage_report. A late closeout can still complete the permit, but it does not move billing-period request counting away from permit issuance.
• Decision and evidence records are tamper-evident on the integrity path; signed exports and externally anchored checkpoints are independently verifiable.
• Replay and idempotency guarantees are route-dependent. Proxy routes have the strongest same-key replay contract; other surfaces have narrower or different semantics.

For coverage boundaries — provider parity, replay scope, permit-first observation, accounting precision, and the integrity proof model — see Scope and Limits.

First request

For the fastest raw API integration, start with the primary public runtime surface:

curl -sS https://api.keelapi.com/v1/execute \
  -H "Authorization: Bearer keel_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: overview-demo-001" \
  -d '{
    "provider": "openai",
    "model": "gpt-4o-mini",
    "input": {
      "messages": [
        {"role": "user", "content": "Explain what Keel does before a model call."}
      ],
      "max_tokens": 80
    }
  }'

If you want one portable execution contract instead, go next to Executions. If you want to decide in your app before executing a model call, start with Permits.

Reading path

• What is Keel for product boundaries and claims
• Quickstart for the fastest first integration
• Recipes for common implementation patterns
• Architecture for the runtime model
• Security, Threat Model, and Known Limits for rollout planning