Named GitHub, files/storage, email, Slack, customer-data, cloud and database reference journeys have registration/control evidence only at its recorded scope. Synthetic/self-hosted fixture evidence does not certify external vendor execution. Live vendor execution is not certified. This proof limitation does not change Keel’s enforcement of exact requests through enrolled managed MCP :call: DENY, unresolved REVIEW and THROTTLE do not dispatch; ALLOW still needs current positive authority and the connector’s verified facts.

Scope and Limits

This page is the operating envelope for Keel: where each surface applies, what each surface 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 has one standard execution model: it evaluates authorization and enforces the decision before consequential downstream execution or dispatch. The table below compares request shapes within that model.

Advanced integrations are available by request for architectures with another trusted enforcement boundary. POST /v1/permits returns a decision and does not dispatch; the external boundary must enforce it before execution. Supplied closeout material is evidence of what was reported, not proof that Keel observed an external side effect.

For the full execution-surface and advanced-pattern comparison, see How Keel Executes Authorized Actions.

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 external-enforcement 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.

Advanced external-enforcement observation

In an advanced external-enforcement integration available by request, 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 an advanced external-enforcement 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.

The standard execution surfaces in the table above enforce blocking decisions before Keel dispatch. An advanced integration must provide its own trusted enforcement boundary; a returned decision alone does not stop an external caller.

Read/write governance coverage

Read/write governance classifies governed actions as read, write, admin, or unknown, with independent risk tags such as spend, value movement, refund, external egress, data export, personal-data access, and code execution. Policies can review or deny writes, admin actions, and risk-tagged actions; Keel’s platform safety floor refuses unknown actions. 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 the number of unknown tools. Unknown, unmapped, or uncertain actions fail closed: Keel refuses them whatever the authored project policy says.

The boundary is route-scoped:

• Keel owns dispatch for supported model/provider requests, managed MCP :call invocations, Stripe MPP/x402 payment.execute, configured connector requests for exact Work actions on projects where AI Permit-to-Work is turned on, and configured Vocal Bridge call.outbound requests.
• The MCP decide and prepare routes are decision-only: they do not call the upstream server, so a trusted customer component owns enforcement.
• GitHub, files/storage, email/Slack, customer-data, cloud, database, payment, and code-tool claims are scoped to an enrolled managed MCP :call, not to every API or credential for the named system.
• Keel does not expose a first-class general Stripe refund rail comparable to payment.execute. The exact stripe.refund.create managed MCP contract is a beta/limited exception: Keel owns dispatch to the enrolled MCP server, so DENY prevents that request from being dispatched and unresolved CHALLENGE holds it before dispatch. The customer-operated adapter owns the final Stripe HTTP call and Stripe TEST credential. Genuine provider-side Stripe TEST refunds have been manually demonstrated; revision-bound automated certification remains pending. Live-mode refunds through the reference adapter are not established. Direct Stripe calls with separate credentials bypass Keel.
• Database access made directly with a scoped credential is downstream-enforced by the database permission system rather than by Keel intercepting a query.
• Other connector maps expand only when exact tool names are audited. If a tool is unmapped, Keel refuses it instead of treating it as read.
• Only connector identities Keel has enrolled (an operator step) can reach a policy allow on a managed MCP :call. A server you register yourself is held for review on every call; a human-approved action mapping can classify its tools, but their calls stay review-only. Starter cannot allow non-payment MCP tool calls, because Basic authoring has no allow and no policy template allows them.
• The mounted browser-action and session code-execution routes dispatch only through an explicitly configured executor. No browser or sandbox runtime is bundled, and none is configured in the current release, so those routes return 503 and dispatch nothing rather than reporting a result they did not produce. The computer-use adapter has no mounted customer route. None of those source implementations is a released execution claim.
• Provider-native code/computer tools run inside the provider. Keel can govern admission of the provider request, but does not intercept each internal tool invocation after dispatch.
• 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 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 uses application-layer encryption for provider credentials, MCP server secrets, MPP project configuration and supported request or fact-opening records. This does not establish encryption for every stored object. Replay responses, execution metadata and deferred payment payloads can remain readable in their stores. Backend storage encryption needs deployment-specific evidence; HTTPS and evidence signatures do not prove it.

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

• Realtime session APIs — in the official public-route and OpenAPI inventory, but session, turn, and sidecar endpoints only produce decisions and evidence; they do not control arbitrary voice media transport or tools invoked off path by the customer runtime. Session responses carry voice_control_status, which is null for every session that is not a native voice session.
• Native voice — native voice session admission is off by default and limited to projects on an explicit activation allowlist. Enrolling a voice adapter on a registered MCP server (PUT /v1/mcp/servers/{server_ref}/voice-adapter) prepares the connector; it does not activate voice, and simulated tests are not provider qualification.
• Operator deployment internals — deployment runbooks, infrastructure topology, and operator-side configuration are part of the deployment guide rather than the public docs.

When operator internals become part of the public surface, they 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, and current attestation status are shared under standard security review — request via security@keelapi.com. The current subprocessor list is public at keelapi.com/subprocessors .

What to rely on

• The decision boundary: a denied Keel 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; a record is covered by a checkpoint only as of the next checkpoint published after it. 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
• How Keel Executes Authorized Actions — execution routes, advanced external enforcement, 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