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.

What this proves: Rewriting history 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 — Anchoring status. The dashboard response confirms the checkpoint cron is running and reports the timestamp of the most recent system tick. The public response omits the project-scoped verification artifact.
  • Production — Verification artifact plus dual witnesses. Adds the project-scoped envelope (checkpoint_id, chain_heads, external-anchor location) and DigiCert / GlobalSign RFC 3161 timestamp receipt attempts when present.
  • Enterprise — Customer-selected TSA eligibility. Same verification artifact and Production witnesses, plus eligibility for a customer-selected TSA and customer-directed trust topology.

RFC 3161 TSA receipts

RFC 3161 timestamp receipts add external timestamp witnesses to checkpoints.

What this proves: An external timestamp witness issued a receipt for the checkpoint 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: Starter receives one FreeTSA-backed witness; Production receives DigiCert and GlobalSign public CA-operated witness attempts; Enterprise adds customer-selected TSA eligibility. See Multi-TSA Configuration for the current ladder and boundaries.

What the stack means together

Governance history is tamper-evident, exports can be independently verified, Production adds dual public CA-operated timestamp witnesses, and Enterprise adds customer-selected TSA eligibility.

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