Scope and Limits

This page is the operating envelope for Keel: where each surface applies, what each integration mode proves, and how to choose the right one. Other pages link here so they can lead with the product behavior and let this page hold the boundaries.

If you are evaluating Keel for a specific workload, the section that matters most is Choosing your integration surface — it answers the buying question directly. The rest of the page is reference for the boundaries you will eventually hit.

Choosing your integration surface

Keel offers two observation patterns, with three Keel-managed routes inside the second.

Use Keel-managed execution when execution-bound enforcement matters — the request does not reach the provider unless governance allows it, and the lifecycle record ties decision to execution to usage. Use decision-only when the caller’s existing provider integration is mature and the value is the decision artifact and evidence trail.

For the full per-mode comparison, see Execution Modes.

Provider coverage

Keel covers OpenAI, Anthropic, Google, xAI, and Meta on the supported public routes. Operation depth varies by provider:

• OpenAI has the broadest operation coverage today: text, streaming, image, audio, embeddings.
• Other providers focus on text generation and streaming, with narrower coverage for advanced operations.

For the current per-provider, per-operation matrix, see Provider Support.

Routing

Routing in Keel is explicit, auditable, and non-autonomous. Every routing-aware request produces a recorded selection — requested target, selected target, the reason for any change, and a fallback history when fallback ran.

Selection never bypasses governance. Permit denials, policy denials, prompt-firewall blocks, authentication failures, and configuration failures stop the request rather than advance through fallback.

For the per-surface routing capabilities, see Routing.

Replay and idempotency

Replay and idempotency guarantees are route-specific by design. Each route family carries the contract appropriate to its execution shape:

• Proxy routes carry the strongest same-key replay binding.
• /v1/executions and /v1/execute carry route-specific idempotency contracts documented per surface.
• Permit replay and permit-first closeout carry their own narrower contracts tailored to the decision-and-closeout shape.

Choose the route that matches the replay strength your workload needs, and parse the per-route contract on Idempotency rather than generalizing across surfaces.

Permit-first observation

In the decision-only pattern, Keel records the decision the caller asked for and any verification material the caller attaches. The caller owns the provider call.

The verification track is the supported way to attach execution-proof evidence to a permit-first integration after the call completes — either a provider receipt or a signed callback. With verification material attached, the permit carries provider-side proof, not just self-reported usage.

When execution-bound enforcement is what you need (the request must not be possible to send if denied), use a Keel-managed execution route from the table above instead of permit-first.

Accounting

Pre-dispatch budget evaluation locks an estimated cost from the project’s envelope before the call leaves the boundary; reconciliation closes the estimate to actual cost after the provider responds.

For multimodal traffic where token estimates are heuristic, the same loop applies: enforce on the estimate, reconcile to actual. When provider-final usage is missing or interrupted, the verification track is the supported path to attach receipt evidence and reconcile against provider-side records.

For the full reconciliation model — verification track, envelope reconciliation, and the financial-reconciliation export — see Reconciliation.

Content inspection

The Prompt Firewall is a deterministic detection layer for well-defined risk patterns — credential leakage, identifier exposure, common prompt-attack shapes, and sensitive resource references. It runs as an inbound check before dispatch on most public execution surfaces, with a strengthen-only baseline customers cannot weaken.

The Prompt Firewall is one defense layer. It is the right layer for deterministic patterns the platform commits to detecting; for open-ended adversarial-content evaluation, layer a content-safety system on top.

For per-surface coverage and the strengthening contract, see Prompt Firewall.

Integrity proof model

Keel’s integrity stack is tamper-evident with externally verifiable witnesses. The stack scales by plan tier, and each layer adds a class of independent verification:

Choose the tier that matches the proof depth your auditors and procurement teams expect. For the layer-by-layer model, see Trust & Integrity; for the verifier procedure, see Verifying Keel Evidence.

Outbound asset fetching

Keel’s outbound policy applies to the destinations Keel itself dispatches to (provider, authentication, billing, governed webhook paths). When a request includes a URL to a remote asset (for example, an image URL passed to a multimodal model), the upstream provider fetches that URL directly.

For workloads that require strict network-layer egress controls, customers can pair Keel managed execution with customer-owned network controls. See Egress-Controlled Deployments.

Auth surfaces

Keel exposes separate auth surfaces for separate purposes:

• Public Runtime API — project API keys for permit, execute, executions, proxy, jobs, and request-timeline routes. This is the integration surface most customers code against.
• Management API — user-JWT dashboard routes for project, policy, provider-key, and billing management.

Authenticate against the surface that matches the workload. For surface stability semantics, see Surface Maturity; for the full route inventory, see Platform Surfaces.

Encryption

Keel documents an encryption-at-rest category model. Provider credentials are encrypted at rest with industry-standard symmetric encryption; signing keys are held under operator-controlled secrets management; stored objects use server-side encryption at the storage layer.

This is a category model, not end-to-end encryption between caller and provider — end-to-end encryption would also require the caller and provider to be encryption endpoints.

For the full model, see Data Handling.

Public-surface boundaries

Two product areas are intentionally outside the current public surface:

• Realtime session APIs.
• Operator deployment internals — deployment runbooks, infrastructure topology, and operator-side configuration are part of the deployment guide rather than the public docs.

When either becomes part of the public surface, it will be documented here.

Compliance and attestation

Keel is designed against the control families enterprise buyers expect to see addressed. The platform produces evidence artifacts that support compliance review — signed exports, externally anchored integrity checkpoints, independent timestamp witnessing, and data-minimized audit records.

Specific vendor questionnaires, personnel and program documentation, key-management procedures, incident-response playbooks, subprocessor lists, and current attestation status are shared under standard security review — request via security@keelapi.com.

What to rely on

• The decision boundary: a denied Keel-managed execution request does not reach the provider.
• The route contracts: each public route’s request shape, response shape, and replay contract are documented and stable on the supported integration surface.
• The evidence model: every governed request produces a permit; signed exports and externally anchored checkpoints are independently verifiable; the verifier is self-contained.
• The plan-tier ladder: capabilities scale by plan, and the matrix is documented on Plans & Entitlements.
• Undocumented behavior is not part of the contract. Treat it as runtime detail that may evolve.

Related pages

• Architecture — public runtime model
• Execution Modes — full per-mode comparison and trade-offs
• Security — runtime boundary, auth, and outbound policy
• Threat Model — conservative public-boundary view
• Data Handling — tenant isolation, transport, and encryption
• Trust & Integrity — integrity layer ladder
• Verifying Keel Evidence — independent verification procedure
• Reconciliation — verification and envelope-reconciliation tracks
• Idempotency — per-route replay contract
• Routing — explicit, recorded selection model
• Prompt Firewall — inbound deterministic detection layer
• Plans & Entitlements — per-tier feature ladder
• Surface Maturity — Runtime API vs Management API stability
• Platform Surfaces — full route inventory
• API Guarantees — public-API stability commitments
• Known Limits — coverage and parity summary