Audit Anchoring

Helix provides tamper-evident, independently verifiable audit logs using a two-layer anchoring scheme: an in-process Merkle tree per tenant, anchored hourly to Sigstore Rekor (a public append-only transparency log) and simultaneously written to S3 Object Lock in COMPLIANCE mode.

Why this matters

A mutable audit log is not an audit log. Any system that can delete or alter its own audit records cannot satisfy HIPAA §164.312(b) (audit controls), GDPR Art.5(2) (accountability), or SOC 2 CC7. Helix's anchoring mechanism makes post-hoc alteration detectable — not just against external attackers but against insider threats including Mabble operators.

Architecture

1. Per-tenant Merkle tree (in-process)

Every audit event that Helix records is appended as a leaf to a per-tenant Merkle tree held in memory. The leaf value is a deterministic hash of the event's canonical JSON representation. Adding a leaf updates the tree's root in O(log n) time.

The Merkle tree is also persisted to Postgres, so the root survives process restarts without losing the in-memory state.

2. Hourly digest (Sigstore Rekor)

Once per hour, a background DigestScheduler goroutine:

1. Reads the current Merkle root and leaf count for each tenant.
2. Signs the digest payload (root + tenant ID + timestamp + leaf count) with Helix's signing key.
3. Submits the signed payload to Sigstore Rekor — a public, append-only log operated by the Open Source Security Foundation (OSSF).
4. Stores the Rekor log entry ID and inclusion proof in Helix's anchor_receipts table.

The Rekor entry is permanently publicly verifiable at https://rekor.sigstore.dev/api/v1/log/entries/<id>.

3. Hourly digest (S3 Object Lock COMPLIANCE)

Simultaneously, the same digest payload is written as a JSON object to an S3 bucket configured with:

• Object Lock mode: COMPLIANCE (not GOVERNANCE — COMPLIANCE cannot be overridden by any AWS principal, including root)
• Retention period: 6 years (HIPAA §164.530(j) retention requirement)

An S3 Object Lock COMPLIANCE-mode object cannot be deleted, overwritten, or shortened in retention by any user, role, or even the bucket owner until the retention date expires.

4. Merkle inclusion proofs

Because Helix uses a standard binary Merkle tree, any individual audit event can be proven to be part of a specific digest without revealing other events. This means:

• A tenant can demonstrate to a regulator that a specific event occurred without disclosing the full audit log.
• Helix can prove a leaf is not in the tree (exclusion proof via the sibling path).

Verification workflow

Use helixctl (Helix's CLI tool) to verify audit anchoring:

# Verify the current Merkle root matches the latest Rekor anchor
helixctl audit-verify --tenant <tenant-id>

# Verify that a specific event is in the Merkle tree
helixctl audit-verify --tenant <tenant-id> --event-id <event-uuid>

# Fetch and display the Rekor entry for a given anchor receipt
helixctl audit-rekor-entry --receipt-id <anchor-receipt-uuid>

The output shows:

• The Merkle root at the time of anchoring
• The Rekor log entry ID (linkable to rekor.sigstore.dev)
• The S3 Object Lock object key and retention date
• The inclusion proof for a specific event (if --event-id is supplied)

Data retention

Storage	Retention	Deletion
Postgres Merkle tree	Indefinite (soft delete on tenant off-boarding)	Manual, with audit trail
Anchor receipts (Postgres)	6 years minimum	Object Lock prevents early deletion
S3 Object Lock digest objects	6 years (COMPLIANCE mode)	Cannot be deleted until retention expires
Sigstore Rekor entries	Permanent (Rekor is append-only)	Not deletable

Threat model

Threat	Mitigation
Helix insider deletes Postgres audit rows	S3 Object Lock (COMPLIANCE) + Rekor remain; Merkle proofs expose the gap
Attacker compromises the Helix signing key	Rekor entries are timestamp-ordered; future entries cannot backdate
AWS account compromise	Rekor is independent of AWS; Rekor entries survive an S3 wipe
Helix process bug corrupts in-memory tree	Postgres persistence restores tree on restart; anchor receipts validate consistency

Open questions / roadmap

• Tenant-controlled verification: Allow tenants to run their own Rekor verification jobs without Helix involvement.
• Cross-tenant transparency: A future public "Helix transparency log" could publish per-tenant root digests without revealing event content, similar to Certificate Transparency.
• Post-quantum signatures: Migrate Rekor signing from ECDSA P-256 to CRYSTALS-Dilithium when Rekor supports PQ algorithms.