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 Growth 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: Business+.

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 / Growth — Anchoring status. The response confirms the checkpoint cron is running and reports the timestamp of the most recent system tick. No verifiable artifact (no URL, no hash, no sequence number).
Business — Verification artifact. Adds the project-scoped envelope: checkpoint_id, chain_heads, and the external-anchor location (bucket, object_key, url) so the customer can fetch the published checkpoint and verify it externally.
Enterprise — Independent timestamp witness. Same verification artifact plus the embedded RFC 3161 TSA receipt (see the next layer).

RFC 3161 TSA receipts

Independent timestamp receipts add a third-party witness to the strongest integrity tier.

What this proves: A third party has witnessed that the checkpoint existed by the claimed time, reducing reliance on Keel alone for timing claims.

Plan requirement: Enterprise.

Enterprise customers can additionally configure multi-witnessed timestamps — adding their own commercial or in-house TSA(s) alongside the default independent witness. This is an early-access enhancement; see Multi-TSA Configuration for the model and how to request it.

What the stack means together

Governance history is tamper-evident, exports can be independently verified, stronger tiers add external anchoring, and the highest tier adds independent timestamp witnessing.

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.

Independent Verification Overview — what the standalone verifier proves and does not prove
Running Keel Verify — CISO walkthrough for signed export verification
Signed Exports — how to request and verify a signed compliance export
Security — the broader security posture
Audit Trails — the public audit surfaces
Configuration Reference — trust hardening env vars