Administrators · Audit
Signed receipts and stored evidence
Besides the audit log, the service keeps signed evidence of important decisions. This article explains what exists and what each piece proves.
Which evidence exists?
| Evidence | What it is |
|---|---|
| Audit events | One record per relevant action, append-only, per organization |
| Chaining | Each event joins a chain of cryptographic digests in the database, in the same transaction |
| ProofFlow approval receipts | A signed record of each approved operation, with the policy decision |
| Third-party request receipts | A signed receipt of each approval or refusal, verifiable by the originating system |
| Privileged access decision receipts | Each decision on a privileged access request |
| Privacy receipts | Each export, rectification or erasure, with counts and digests |
| Sealed recordings | Privileged sessions, anchored in the audit chain |
How are receipts signed?
With two signatures: Ed25519 and ML-DSA-65 (a post-quantum algorithm), with keys held in the key management service. They can be verified outside the service with the installation's public keys.
What the evidence proves, and what it does not
- It proves an action happened, with which identities, which outcome and when, according to the server.
- Receipts prove that exact operation was approved.
- It is not a qualified signature and carries no third-party timestamp.
- The audit JSON copy made in the console is unsigned and proves neither integrity nor completeness.
Verifying a receipt
Verification is described for developers in Verify receipts. If the console shows «The signed receipt does not match the expected authorization, result, or policy evidence.», treat it as an incident and contact support.
Error codes in this article
Was this page helpful?
Thank you. Your answer stays in this browser; nothing is sent.
Sorry about that. Try:
- searching for the exact text of the message or the error code
- the error code index
- asking your organization's administrator