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-controlled execution paths configured through the dashboard are the standard product experience. Permit-first is an advanced integration for architectures in which the caller must retain provider transport. The table below compares the resulting observation boundaries.

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 receipt or callback evidence to a permit-first integration after the caller-owned call completes. Keel records the supplied material and its verification state. The generic path does not independently establish provider origin, direct observation by Keel, or that the ultimate external side effect occurred.

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.

Read/write governance coverage

Read/write governance classifies governed actions as read, write, admin, or unknown, with independent risk tags for spend, external egress, data export, and code execution. Policies can review or deny writes, admin actions, risk-tagged actions, and unknown tools. Evidence records the classification, registry version, policy decision, and permit context for actions that route through Keel.

The classifier is registry-backed. Coverage reports expose the registry version, registry hash, classifier schema version, and per-connector counts such as N of M tools classified and K unknown -> review. Unknown, unmapped, or uncertain actions must fail closed into review or deny according to the authored project policy.

The boundary is route-scoped:

• Keel governs model calls, MCP tools, payments, code execution, and credential-scoped database access when they route through Keel.
• The deepest coverage today is GitHub and credential-scoped databases. GitHub has the broadest curated connector map; databases rely on verified read-only or read-write credentials rather than SQL parsing.
• Other connector maps expand only when exact tool names are audited. If a tool is unmapped, it reviews by default instead of being treated as read.
• Browser and computer-use actions are coarse unless the concrete action is mediated by a governed tool or route.
• Direct calls made off path with the agent’s own provider, API, browser, database, or tool credentials are not governed by Keel.
• Action classification evidence proves what Keel classified, decided, and recorded under the registry version/hash. It does not prove that the business decision was correct or that an unproxied side effect did not happen elsewhere.

For setup and policy examples, see Read/Write Governance.

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, RFC 3161 timestamp receipts, 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 AI Permit records decision evidence. Signed exports and externally anchored checkpoints on supported plans provide independently verifiable integrity material for the records they contain; the verifier checks the supplied bundle, not completeness or external truth.
• 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
• Read/Write Governance — action access policy and coverage boundaries
• 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