Skip to Content
Trust & Integrity

Trust & Integrity

Keel’s public integrity model has four layers. They are designed to strengthen audit confidence without claiming that every record on every surface has the same proof properties.

What each layer proves

Tamper-evident governance history

Governance history is tamper-evident within Keel’s integrity boundary.

What this proves: Later integrity review can detect silent insertion, deletion, or modification inside the covered governance history.

Plan requirement: Baseline integrity coverage on every plan; programmatic readback of chain state via the integrity verification API requires Production or higher. See Verifying Keel Evidence § Programmatic chain verification for the API contract.

For a CISO-facing workflow that exports the chain entries and verifies them outside Keel, see Independent Verification Overview and Running Keel Verify.

Signed compliance exports

Signed exports let customers verify that an exported compliance package has not been altered after it left Keel.

What this proves: The exported package can be independently verified after delivery. See Signed Exports.

Plan requirement: Production+.

External integrity checkpoints

External checkpoints anchor integrity state outside the primary operational data path.

A checkpoint commits to per-project chain heads as of its publication time. It covers events recorded before it was published and establishes that they existed by then, not at their own time. Its timestamp receipts likewise witness the checkpoint time, not the event time.

What this proves: For the history a checkpoint covers, rewriting it becomes materially harder because the integrity state is also anchored outside the primary operational store.

Plan requirement (visibility-tiered). The latest-checkpoint surface (GET /v1/dashboard/projects/{project_id}/integrity/latest-checkpoint) is reachable on every plan, but the level of detail in the response depends on tier:

  • Starter — Checkpoint status. The dashboard response reports when the most recent system-wide checkpoint was published. The response omits the project-scoped verification artifact.
  • Production and Enterprise — Verification artifact. Adds the project-scoped envelope (checkpoint_id, chain_heads, external-anchor location) and any DigiCert / GlobalSign RFC 3161 timestamp receipts and attempts the checkpoint carries.

Customer-selected timestamp authorities and customer-directed trust topologies are not available on hosted Keel.

Publication history

No checkpoints were published from 2026-08-16 to 2026-11-03. Events from that window are covered by the first checkpoint published after it, which establishes they existed by then, not at their own time.

RFC 3161 TSA receipts

RFC 3161 timestamp receipts add external timestamp witnesses to checkpoints and to voice session attestations.

What this proves: An external timestamp witness issued a receipt for the covered hash by the recorded time. With a configured TSA CA bundle, OpenSSL-backed authenticity validation can also check CMS signature, configured trust-store chain, and timestamp-signing purpose.

Plan requirement: Where timestamping is enabled, Keel requests receipts from the providers the plan includes: FreeTSA and DigiCert on Starter, DigiCert and GlobalSign on Production and Enterprise. Starter checkpoint views show status only, with no receipt. Each request is best effort, and failed attempts are recorded. Keel requests checkpoint receipts only when it publishes a checkpoint, so an event is TSA-witnessed only as of the next checkpoint published after it. Customer-selected timestamp authorities are not available on hosted Keel. See Multi-TSA Configuration for the ladder and boundaries.

What the stack means together

Governance history is tamper-evident, exports can be independently verified against Keel’s published keys, and checkpoints with timestamp receipts witness the history they cover.

The layers are meant to reduce single-surface trust assumptions, but they are not a claim of universal or perfect proof across every Keel record.

What the stack does not claim

For the precise scope of what the stack proves — and what it does not — see Scope and Limits § Integrity proof model. In short: tamper-evident with externally verifiable witnesses, not per-record cryptographic immunity, and not a substitute for a full compliance program.

Last updated on Edit this page on GitHub 
Egress-Controlled DeploymentsSigned Exports