Skip to Content
Trust Overview

Keel Trust Overview

Summary

Keel provides agent control infrastructure. In architecture terms, it acts as a control plane for the supported AI execution paths integrated with Keel. On Keel execution routes, decisions about whether a request may proceed are made before provider dispatch and captured as decision evidence.

An AI Permit is a pre-execution decision record. It may allow, deny, throttle or require review. Only an allow decision authorizes execution.

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 execution routes.
  • Audit evidence is tamper-evident. Supported signed exports and integrity artifacts are externally verifiable on the plans that expose them.
  • Compliance exports are independently verifiable without contacting Keel.
  • Signed execution-closure and MCP tool-call evidence use content digests; separate replay and recovery records can retain 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 execution routes, a non-conforming request is stopped before provider execution, the decision is captured in evidence, and, when a Permit names a budget envelope, its estimated cost is reserved against that envelope.

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.

AI Permits as Decision Evidence

AI Permit issuance and supported execution routes produce an AI Permit. Dry-run evaluation does not issue or persist one. The AI Permit captures the structured request context, decision and reason, matched policy reference, applied constraints and budget state at decision time. AI Permits exist whether or not the intended action is ultimately executed.

AI Permits — together with the broader governance event stream — form the canonical decision-evidence substrate. Operational logs are diagnostic and are not the audit record.

See AI Permits for the full decision-record 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 offline with industry-standard public-key cryptography, once you have Keel’s trust root (the independently retrieved key manifest or the verifier’s bundled root). A key embedded only in the artifact proves self-consistency, not Keel authenticity.
  • Externally anchored checkpoints. Evidence checkpoints are published to a storage surface outside Keel’s runtime. A checkpoint establishes that the events it covers existed by its publication time, not at their own time.
  • RFC 3161 timestamp receipts provide external timestamp witnesses where timestamping is enabled: FreeTSA and DigiCert on Starter, DigiCert and GlobalSign on Production and Enterprise, each best effort. Starter checkpoint views show status only, with no receipt. Customer-selected timestamp authorities are not available on hosted Keel.
  • 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

Signed execution-closure and MCP tool-call evidence use request and result digests rather than full provider bodies. Separate execution and replay stores can retain provider-native, normalized, or truncated response content. Supported async, review/resume, and recovery flows can retain recoverable encrypted request content.

Keel also retains route-appropriate token counts, provider and model identifiers, cost, request and decision identifiers, timestamps, policy references, constraints, and budget accounting. Metadata can contain personal data. Retention and deletion are store- and surface-specific; see Data Minimization and Data Handling.

Cost Control

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

  • When a Permit names a budget envelope (budget_envelope_id), its estimated cost is reserved against that envelope at decision time; a request whose estimated cost cannot be reserved is refused (budget_envelope_exhausted). POST /v1/execute accepts budget_envelope_id too; POST /v1/executions and the proxy routes use project cost caps instead.
  • 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.

  • One standard execution model. Keel evaluates authorization and enforces the decision before downstream execution or dispatch. Advanced integrations are available by request where another trusted system owns enforcement and dispatch. Decision or preparation primitives do not themselves dispatch, and caller-reported closeout does not prove an external side effect.
  • 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.
  • One shared hosted deployment. Keel runs as a single shared hosted service. Dedicated, single-tenant, regional, self-hosted, and customer-cloud deployments are not offered. Customers with strict isolation, residency, or availability requirements should review that model with Keel before signing.
  • 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