Immutable Ledger

The Immutable Ledger is the audit backbone of the platform. Every policy decision, every key release, every revocation, and every administrative change is anchored to a distributed, tamper-evident record. It is the mechanism that turns "we believe our logs are intact" into evidence that a regulator, an internal auditor, or a legal counterparty can rely on.

What gets recorded

At minimum, every decision event captures:

• The data object identity the decision was about.
• The principal who made the request (resolved to their tenant-scoped identity, never raw identity-provider credentials).
• The policy version evaluated.
• The outcome: allow, deny, or error, plus any obligations attached to an allow.
• The time of the evaluation, signed into the record.
• The decision identifier that later ties the unwrap event (if any) back to the authorizing decision.

Administrative events (policy changes, tag schema changes, key rotations, tenant configuration changes) are recorded in the same ledger with an analogous structure. Who, what, when, and what it replaced.

Why immutability matters

A conventional audit database, even a well-configured one, is mutable. An attacker with sufficient privilege can alter or delete records. A mistake in a schema migration can lose them. A compliance freeze can be quietly bypassed.

The ledger's append-only, distributed structure makes after-the-fact modification computationally infeasible. Every record is cryptographically bound to the records before it, and the chain is replicated across tenant-controlled nodes. Tampering requires rewriting the chain on a majority of nodes simultaneously — a threshold that is impractical for any realistic attacker.

Bidirectional proof

The ledger provides two kinds of evidence, both of which are often needed:

• The presence of a record proves that a specific access occurred, at a specific time, under a specific authority.
• The absence of a record proves that a claimed access did not occur. For any tenant-bounded time window, the complete set of decisions for a given object is enumerable, and a record that is missing really is missing.

Conventional systems can produce the first kind of evidence but struggle with the second.

What customers can do with it

Regulatory evidence packs. For frameworks that require documented access controls and demonstrable evidence — GDPR, HIPAA, CMMC, FedRAMP, financial services supervisory frameworks — the tenant administrator can export a signed evidence pack for a specific data object, a specific principal, or a specific time window.

Incident response. When an incident affects a specific set of data, the question of "who accessed these records between date X and date Y" becomes a ledger query, not a log correlation exercise.

Partner and vendor accountability. In coalition or third-party-risk scenarios, each party can inspect the ledger entries bound to their participation without seeing other parties' unrelated activity. This is the mechanism that makes data-centric third-party risk management possible.

Legal hold and discovery. Ledger records can be frozen for a custody period. Because the records are immutable, the chain of custody is unbroken from recording through production.

What isn't in the ledger

By design:

• The data itself. The ledger records who accessed what — never what the data contains. Payload cleartext is never written to the ledger.
• The policy contents at decision time. The ledger references the policy version. The policy content itself is stored in the tenant's policy repository. Historical versions are retained long enough to reconstruct past decisions.
• Identity-provider internal tokens or credentials. The ledger records the tenant-scoped principal identifier, not the originating token.

This separation is deliberate. A ledger that recorded the data or the full policy context would itself become a sensitive exposure.

Relationship to other concepts

• Every policy decision produces a ledger record.
• Every KAS unwrap event produces a ledger record.
• The ledger is the substrate for the evidence export capability described under Configuration → Audit and Evidence.