Overview

Keel evaluates supported actions against customer-defined authorization rules before dispatch. It records the decision and associated evidence. Blocking outcomes are not dispatched through Keel.

Customers create a project, connect providers, configure policies and controls, and inspect decisions, costs, activity, and evidence in the dashboard. Applications must connect through a supported SDK or API; opening the dashboard does not put external actions under Keel’s control.

Keel in one minute

• Keel provides agent control infrastructure.
• It evaluates authorization and enforces the decision before downstream execution or dispatch.
• Every issued AI Permit records decision evidence. Execution surfaces add lifecycle facts they can observe.
• Authorization or release does not by itself prove an ultimate external effect.

Connect your application

Start with Quickstart and a supported SDK, or the Execute API example below. Configure credentials and authorization rules, send a supported request, and inspect its decision and evidence. Keel does not control requests made directly to other systems.

For API formats, operation-specific support, and dispatch responsibilities, see How Keel Executes Authorized Actions. A separate /v1/permits request is not required when Keel executes the request. Proxy response shapes depend on the selected route; see Proxy Execution.

Public execution flow

Advanced integrations — by request

Where another trusted system already owns enforcement and dispatch, an advanced integration can use decision or preparation primitives. POST /v1/permits returns a decision and does not dispatch. The external boundary must enforce that decision and its constraints before execution; Keel does not directly observe its provider call. Caller-reported closeout remains evidence of supplied observations, not proof of an ultimate external effect.

Evidence verification

Use released keel-verifier==3.28.0 with trusted public signing material. A verification succeeds only when every requested, required claim is supported. See Running Keel Verify.

Guarantees and boundaries

See API Guarantees, Route Guarantees, and Scope and Limits for provider coverage, replay, accounting, content handling, and evidence boundaries.

First request

For the fastest raw API integration, start with the primary public runtime surface. Hosted Keel requires a current X-Keel-Timestamp and a new X-Keel-Nonce on every request to this route; without them it returns 401 request_not_fresh. See Request Freshness.

curl -sS https://api.keelapi.com/v1/execute \
  -H "Authorization: Bearer keel_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -H "X-Keel-Timestamp: $(date +%s)" \
  -H "X-Keel-Nonce: $(openssl rand -hex 16)" \
  -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. For an advanced integration with another trusted enforcement boundary, request integration guidance; Permits describes the decision primitive.

Reading path

• Why Keel for the problem Keel solves and when to adopt it
• Product Boundary for public surfaces and non-claims
• Quickstart for the fastest first integration
• Recipes for common implementation patterns
• Architecture for the runtime model
• Security, Threat Model, and Scope and Limits for rollout planning