Skip to Content
Trust Overview

Keel Trust Overview

Summary

Keel is a control plane for AI execution. On Keel-managed routes, decisions about whether a request may proceed are made before any provider call leaves the boundary, captured as durable evidence, and made available for independent verification.

A permit is the recorded decision Keel makes before an AI call runs. Each governed request produces a permit; the permit is the audit artifact a reviewer reads back later.

This overview is intended for security, compliance, and architecture reviewers evaluating Keel for enterprise adoption. It describes what the platform controls, the evidence it produces, and how to align a deployment with internal review processes.

  • Decisions are made before provider calls leave the boundary on managed routes.
  • Audit evidence is tamper-evident and externally verifiable.
  • Compliance exports are independently verifiable without contacting Keel.
  • Audit records do not contain raw prompt or completion content.
  • The platform’s posture and scope are documented openly.

What Keel Controls

Keel evaluates each governed request against the project’s policy and budget context. On managed execution routes, a non-conforming request is stopped before provider execution, the decision is captured in evidence, and cost is reserved against budget envelopes before dispatch.

The decision model returns a small, well-defined set of outcomes covering allow, deny, throttle, and human-review paths. Evaluation is consistent and predictable.

Keel deliberately favors a clear enforcement boundary over open-ended interception. Capabilities outside that boundary — such as model hosting or autonomous routing across providers — are intentionally outside the platform’s scope.

Permits as Audit Evidence

Each governed request produces a permit, a persisted decision record that captures the structured request context, the decision and its reason, the matched policy reference, applied constraints, and the budget state at decision time. Permits exist whether or not the request is ultimately executed.

Permits — together with the broader governance event stream — form the canonical audit substrate. Operational logs are diagnostic and are not the audit record. Compliance reviewers should treat the permit and governance event stream as the authoritative source.

See Permits for the full permit model.

Evidence Integrity

The evidence substrate is designed for after-the-fact review by an external auditor.

  • Tamper-evident chain. Modifications to governance evidence are detectable on later review.
  • Signed compliance exports. Exports carry a manifest verifiable with industry-standard public-key cryptography using only the export artifact and standard tooling. No callback to Keel is required.
  • Externally anchored checkpoints. Evidence checkpoints are anchored to an independent storage surface available to the customer.
  • Independent third-party timestamp witnessing is available for higher tiers, providing a witness that a checkpoint existed at or before a recorded time.
  • A published verification procedure walks an external party through reconciling exports, checkpoints, timestamp receipts, and the public key manifest.

The integrity stack is positioned as tamper-evident with externally verifiable witnesses. For the precise scope of what the stack proves and does not prove, see Scope and Limits § Integrity proof model.

See Trust & Integrity and Signed Exports for layer-by-layer detail.

Data Minimization

The audit substrate is data-minimized by default.

  • Raw prompt content is not persisted in the audit record.
  • Raw completion content is not persisted in the audit record.
  • Tool call and tool result payloads are not persisted in raw form.
  • Multimodal payload bytes are not persisted.

What is persisted: token counts, provider and model identifiers, cost, request and decision identifiers, timestamps, decision metadata, matched policy references, applied constraints, and budget accounting.

This default reduces indirect data residency exposure for sensitive workloads and simplifies data-handling reviews.

Cost Control

Cost controls are enforced before dispatch rather than observed after the fact.

  • Estimated cost is reserved against the project’s budget envelope at decision time. A request whose estimated cost cannot be reserved is stopped before dispatch.
  • Cost policy expresses short-window, periodic-window, spike, and trajectory considerations.
  • Actual cost is reconciled with the reservation after the call completes.
  • Cost telemetry and audit evidence derive from the same persisted records and are mutually reconcilable.

For highly multimodal payloads, pre-dispatch estimation is approximate; reconciliation closes the difference after the call.

Identity and Access Context

  • Project is the primary tenancy boundary. Public runtime endpoints authenticate into a project.
  • Project credentials are stored securely; raw credential material is shown once at creation and never returned afterward.
  • Provider credentials are stored server-side, encrypted at rest with industry-standard symmetric encryption, and never returned in raw form.
  • Subject identity supplied with the request flows into the policy evaluation context.
  • Production execution routes include replay protections.
  • Cross-tenant data isolation is enforced at multiple layers, with deployment specifics reviewed alongside the customer during onboarding.

See Security and Data Handling for full detail.

Compliance and Vendor Review

Keel is designed against the control families enterprise buyers expect to see addressed.

  • Access controls. Project-scoped credentials with one-time disclosure, encrypted upstream credential storage, multi-layer tenant isolation, and structured redaction of sensitive keys in operational logs.
  • Anomaly detection and behavioral thresholds. A comprehensive governance event stream covering decisions, executions, and reconciliation; tamper-evident review; spike detection and adaptive throttling as first-class capabilities.
  • Change management and traceability. Public surface tiering with deprecation commitments on stable contracts, preserved decision context on supported tiers, and signed exports with post-delivery verifiability.

The platform does not claim third-party attestations it has not completed. The architecture is designed to support evidence export against major frameworks, which is a different commitment from an executed attestation.

Detailed vendor questionnaires, personnel and program documentation, key management procedures, incident response playbooks, and tenant isolation specifics are available under standard security review.

Deployment Considerations

A small number of design choices are worth aligning on during onboarding.

  • Managed execution vs. decision-only. On managed execution routes, decisions are enforced and Keel issues the provider call. The decision-only mode is advisory by design and appropriate for caller-controlled execution; for execution-bound enforcement, managed execution is the recommended pattern.
  • Layered content controls. Built-in content inspection focuses on well-defined risk patterns. Workloads requiring open-ended semantic content evaluation are appropriate for layered deployments.
  • Tenant isolation alignment. Customers with strict isolation requirements can review the deployment model with Keel during onboarding to confirm fit.
  • Availability topology. Customers with regional residency or active-active availability requirements can align on deployment topology with Keel before signature.
  • Attestation alignment. Buyers whose procurement processes reference a specific attestation can align on the current attestation roadmap as part of vendor review.

These items are aligned through standard onboarding rather than through the public documentation surface.

Last updated on Edit this page on GitHub 
Request FreshnessSecurity