Helix Hub trust model (one page)

Helix Hub is a control plane. The security boundary is the offline‑verifiable proof object (bundle + digests + receipts).

This doc states what Hub can and cannot lie about, and what must be true when verification passes.

Threat framing

Assume:

• Hub is reachable but may be buggy, misconfigured, or compromised.
• Runners execute in customer environments (on‑prem / VPC) and can be compromised too.
• Reviewers need to validate evidence without trusting Hub (offline).

Goal:

• A party who receives a bundle can verify integrity, provenance, and approval lineage deterministically from bytes on disk.

Non‑goal:

• “Biological truth.” Helix is an in‑silico decision/evidence system; verification proves computational provenance and integrity only.

What Hub can lie about

Hub can lie or be wrong about:

• UI rendering or summaries (misleading dashboards, truncated diffs).
• Availability/completeness of server‑side logs (deleted/withheld events).
• Access control bugs (showing an object to the wrong user).
• Queue state (claiming a job was run when it was not).

Therefore: treat Hub as an index, not the source of truth.

What Hub cannot lie about (if offline verification passes)

If a verifier accepts a bundle:

• Artifact bytes match the manifest digests (no silent substitution).
• Receipt bytes match their referenced digests (no silent receipt substitution).
• Receipt signatures verify against a pinned trust root (the signer identity is cryptographically proven).
• Approval receipts bind to an approval surface digest, which binds to the bundle core digest and policy digest (reviewers approved that exact surface).

Hub cannot rewrite history without producing a different bundle digest and invalidating previously shared proof.

Key trust + rotation

Two key classes:

• Runner keys: sign run receipts (who executed).
• Hub/reviewer keys: sign approval/audit receipts (who approved/exported).

Trust distribution rules:

• Verifiers must be configured with trusted public keys (key_id → pubkey) per workspace/project.
• Key rotation must be overlap‑based: old + new keys valid for a window, with explicit not_before/not_after metadata (or equivalent policy rules).
• Key compromise response is a policy action: revoke key id for future receipts; do not silently rewrite old bundles.

Failure modes (designed to be loud)

Verification must fail closed on:

• Integrity failures are detectable either as structured parse/canonicalization failures (for JSON artifacts) or as sha mismatches (for opaque artifacts); both are hard fails.
• Missing referenced blob/receipt
• Digest mismatch (bytes drift)
• Unknown schema id
• Unknown canonicalization id
• Signature mismatch / untrusted signer (when signatures are required)
• Receipt binds to the wrong bundle core digest or policy digest

Minimal buyer‑credible claim

“Any external reviewer can verify a decision bundle offline and detect drift, tampering, or unapproved outputs in under 30 seconds.”