Verify our audit log without asking us.

An audit log is evidence only if nobody can quietly edit it afterwards. Pramaan adds each audit event to a tamper-evident log, and anyone can check its signed summary, with no account. This page shows how, and says what that proves and what it does not.

What the log is

Illustrative
An event
The log
Anyone checks

Every audit event is added to the log. There is no switch: the log is written unconditionally. The broker signs a summary of every entry so far, and serves it, with the proofs that check it, to anyone with no credentials, because they expose only hashes. The events themselves are private: reading them needs an access token, and an account that is not an administrator sees only its own events. The checks are yours to run; the commands are in the technical detail below.

What the log proves, and what it does not

Illustrative
The log
Integrity
Not completeness

The log proves the integrity of recorded events; it is not proof that every decision was recorded.

Change, reorder or remove a recorded event and the signed summary changes, so a check against a summary you kept will fail. Whether each security decision produced an event at all is a separate property, checked by reading the code that records events, not by reading the log.

For your engineers

Technical detail: check it yourself

Illustrative
Your machine
Fetch and verify
Matches

Run these from any machine. None of them needs an account.

Fetch the signed tree head. Keep the reply: tree_size and root_hash are what you check later proofs against, sth_jwt is the same head signed as an ES256 JWT (only the JWT is signed, so check that its tree_size and root_hash equal the reply's), and pq_anchor is the post-quantum signature described below.

curl -s https://id.pramaanid.cloud/transparency/sth

Fetch the published keys. The kid in the JWT's header names the key that signed it; check the ES256 signature with that key, using a JOSE library you trust. A head that verifies was signed with the broker's key, whoever handed it to you.

curl -s https://id.pramaanid.cloud/jwks

Later, ask for a consistency proof from the size you kept to a newer one. Replace OLD_SIZE with the tree_size you kept and NEW_SIZE with the one in a fresh tree head. The first_root in the reply must equal the root_hash you kept, and second_root the root_hash of the fresh head whose signature you checked; recomputing both roots from proof with the RFC 6962 algorithm shows the older tree is an exact prefix of the newer one.

curl -s 'https://id.pramaanid.cloud/transparency/proof/consistency?first=OLD_SIZE&second=NEW_SIZE'

The recipe above checks the tree head's ES256 signature and that later tree heads are consistent with one you kept; it does not check the post-quantum anchor.

What the signatures are

Illustrative
Tree head
Signed
Verified

The tree head is signed with ES256, by the key the broker publishes at /jwks. When a post-quantum key is configured, the head also carries an SLH-DSA-SHA2-128f anchor (FIPS 205) over the root hash, with its public key in the pq_anchor field.

Inclusion and consistency

Illustrative
An event
Proof path
In the log

An inclusion proof shows that one event's leaf is in the tree of a given size: the leaf hash and the hashes on its path recompute to that tree's root. It answers "is this event in the log?" A consistency proof shows that a smaller tree is an exact prefix of a larger one. It answers "has anything recorded changed since I last looked?"

Inclusion needs an event's leaf hash, and events are private, so it starts from your own account. The account console fetches your events, asks /transparency/proof/inclusion?hash=LEAF_HASH&size=TREE_SIZE for each, and recomputes the proof and the tree head's ES256 signature in your browser.

Questions

Do I need an account to check the log?

Not to check the signed summary, its signature or that the log has only grown: the broker serves them to anyone, with no credentials. Checking that one particular event is in the log needs that event's own hash, and events are private, so that check starts from your own account.

Could the operator rewrite the log and sign it again?

The operator of a broker holds its signing key, so it could sign a new summary over a rewritten log. It could not make that summary consistent with one you kept: the check from your copy would fail. Keeping a signed summary is what makes a rewrite visible.

What does the post-quantum signature add?

When a post-quantum key is configured, each signed summary also carries a second, post-quantum signature over the root hash. No browser view checks it; checking it needs software of your own.

Why keep a signed summary from earlier?

The check compares an older size of the log with a newer one. Without a summary you saved earlier there is nothing to compare today's against. It protects what the log held when you saved your copy; it cannot tell you whether the log was altered before then.

Talk to us, or try it first

  1. Book a walkthrough

    Against your own apps, not slides.

  2. Run the lab

    It uses a demonstration account; none of your data is involved.

  3. See pricing

    Published floors, named-user bands and what every tier includes.