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.

The standard Keel product experience starts in the dashboard. Customers create a project, connect providers, configure policies and controls, and inspect decisions, costs, activity, and evidence there. Supported agent actions then run through Keel-controlled execution paths so policy can be enforced before dispatch and the resulting lifecycle can be recorded in the dashboard.

For customers that must retain their own execution layer, Keel also supports an advanced permit-first integration through POST /v1/permits. The caller requests the pre-execution decision and remains responsible for enforcement, provider execution, and closeout.

Keel in one minute

• Keel provides agent control infrastructure.
• It issues AI permits before consequential actions and produces route-appropriate evidence after.
• POST /v1/execute is the primary public runtime surface. POST /v1/executions is the underlying provider-neutral execution contract. POST /v1/permits is the public decision seam for advanced permit-first integrations.
• On Keel-managed routes, denied requests do not reach a provider.
• Every AI Permit records decision evidence. Managed execution and supported closeout flows can add lifecycle and execution evidence.

Integration patterns

Most teams start with the SDK provider wrappers. Calls made through those wrappers use Keel’s supported decision and execution path; calls made outside the integration remain outside that path. The wrappers handle AI Permit evaluation, budget enforcement, provider dispatch, and usage reporting.

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

• 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
• POST /v1/permits as an advanced decision-first integration when your app must own the provider call

Use the execution routes for the standard Keel-controlled path in which Keel enforces policy and calls the provider. Use permit-first when your architecture requires your application to retain enforcement and provider execution.

Permits and executions

Execution routes (/v1/executions, /v1/execute, /v1/proxy/*) automatically evaluate an AI Permit 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 obtain the decision, then enforce that decision and any constraints before calling the provider.

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: every AI Permit records decision evidence; managed execution and supported closeout flows can add dispatch, provider-response, usage, cost, delivery, or closure evidence.

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

• /v1/permits returns an AI Permit and leaves downstream enforcement and 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.

Guarantees and boundaries

For the public commitment model, use API Guarantees. For route-by-route trust properties, use Route Guarantees. For provider parity, replay scope, permit-first observation, accounting precision, and integrity-proof boundaries, use 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

• 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