WRNexus
Back to the blog
security 6 min read

Inside the WRNexus audit log: a tamper-evident hash chain

How we build an append-only, auditor-friendly trail of every sensitive action — and why we chose a hash chain over a signed-row scheme.

Rohan Verma

#security · #audit · #compliance

When your auditor asks “show me every time an admin elevated themselves to owner in the last 90 days,” the answer should take seconds, not a sprint. WRNexus ships with an opinionated audit log that makes those questions boringly easy — and proves, cryptographically, that nothing was deleted on the way.

The shape of an entry

Every entry captures the actor, action, target, metadata, IP, user-agent, and the prev_hash of the entry directly before it. The current row’s hash field is SHA256(prev_hash || canonical_json), so any in-place edit instantly invalidates every later row.

{
  "id": "ae_01HX…",
  "actor": { "type": "user", "id": "usr_…", "email": "rohan@wrnexus.com" },
  "action": "workspace.member.role_changed",
  "target": { "type": "membership", "id": "wsm_…" },
  "metadata": { "from": "admin", "to": "owner" },
  "ip": "203.0.113.42",
  "occurred_at": "2026-05-08T11:14:02Z",
  "prev_hash": "8c0f…91e3",
  "hash":      "1b27…ef04"
}

Why a hash chain, not per-row signatures?

We considered three designs:

  1. Per-row HMAC — every row signed with a server-side secret.
  2. Per-row asymmetric signature — every row signed with a private key the customer holds.
  3. Hash chain — every row’s hash is SHA256(prev_hash || row).

The hash chain wins for our threat model because it requires zero customer-side key management and makes a deletion attack visible without needing to verify every row individually. The auditor only needs the current head hash — which we publish daily to a transparency log — and a copy of the rows, to verify the entire chain.

What we record

The full list lives in docs/audit-events.md, but the headline categories are:

  • Authentication — sign-in, sign-out, MFA enroll/disable, password reset.
  • Workspace — create, rename, delete, member invite, member role change.
  • Billing — plan change, payment method update, invoice generated.
  • Security — impersonation start/stop, admin action against a customer.
  • Compliance — data export, account deletion, retention purge.

Exports & streaming

CSV and JSON exports are available on every tier. Enterprise customers can stream the same feed to BigQuery, Snowflake or Redshift — the JSON shape on the warehouse is identical to the API response, so any view you build on your own data lands on the same column names.

That parity is the point of the whole system: the trail your auditor sees is the same trail your support engineers see when triaging an incident, which is the same trail you query when answering “did anything change last Tuesday?”