Auditing activity
Every change is recorded: what changed, who changed it, when, and what the value was before and after.
Append-only in normal operation
The audit log. Entries are append-only — the database refuses updates and deletes.
Ordinary writes cannot modify or delete an audit entry. A database trigger refuses updates and deletes, so no application code path and no ordinary caller — however privileged — can rewrite history.
This matters because an audit log that ordinary operations can edit proves nothing.
A dedicated retention endpoint, gated on its own permission, temporarily disables that trigger and deletes entries older than the retention window — from the audit log and the security audit log alike.
This is deliberate, because unbounded retention is not lawful everywhere. But it means immutability is a property of normal operation, not an absolute. Treat the purge permission as one of the most sensitive in the platform: it is the only capability that can remove evidence, and the purge itself is the thing to monitor.
Gaps
Entries carry a monotonically increasing sequence number, so a removed entry leaves a visible hole.
A gap is not proof of tampering. A sanctioned retention purge produces exactly the same signal. Read a gap as "entries are missing here", then establish whether a purge covers that window before concluding anything further.
What is recorded
| Recorded | Detail |
|---|---|
| Event type | What happened |
| Actor | Who did it |
| Resource | What it happened to |
| Before and after | The values that changed |
| Timestamp | When |
| Sequence | Position in the total order |
Security-relevant events — sign-ins, permission grants, policy changes, masking changes — are recorded separately from ordinary data changes, so a security review is not searching through routine record edits.
Masking applies to audit entries too
Before-and-after values can contain sensitive data, so masking applies to them exactly as it does to entity attributes.
Who did something is never redacted. Masking a sensitive value in a change record is correct; hiding who made the change would defeat the purpose of an audit trail. If someone should not see audit entries at all, withhold the audit permission rather than masking the actor.
Retention
Retention is enforced by the purge endpoint described above, which deletes entries older than a configurable window. Export anything you must keep for longer before it falls outside that window — a purge is not recoverable from within the platform.
Audit versus history
Two different things, easily confused:
| Answers | |
|---|---|
| Audit log | Who did what, and when |
| Temporal history | What a record looked like at a point in time |
Use the audit log to investigate an action. Use history to reconstruct a state.
Next
Last verified against commit 315eb047 (2026-08-03)