Dashboard: Audit Trail

Route: /observability/audit (AuditTrail.tsx)

The console's view onto the same hash-chained audit log the CLI/API expose — a paginated, JSON-rendered entry list with export and deep-linking, not a re-implementation of the audit store itself.

What it shows

A card listing {total} entries (page {page}), followed by the raw entry list rendered as syntax-highlighted JSON (CodeHighlight, not a structured table — every field on the entry is visible, nothing is summarized away). Backed by GET /observability/audit?page_size=50&run_id=<id> — a console-surface-internal route, distinct from the main API's GET /security/audit (see reference/api/security.md).

Filtering by run

The page reads a ?run_id= query parameter and, when present, scopes the query and changes the header to "Filtered to run <id>". This is how deep links from other screens work — Run Detail, Incidents, and Metrics' cost-spike drill-down all link here with run_id set, rather than each screen re-implementing its own audit view.

There is no other filtering UI today (no date range, actor, or category picker) — run_id is the only supported scope beyond the default unfiltered feed.

Export

Two buttons, both hitting GET /export?dataset=audit_trail&format=<csv|report>:

  • Export CSV — a flat CSV of the current audit entries
  • Export Report — a formatted report (PDF-style summary), distinct from the CSV dump

Both trigger a browser download (blob URL + synthetic <a download> click) rather than opening in a new tab.

Relationship to the compliance evidence engine

This page is the audit log — a record of what happened. It's a different mechanism from the compliance evidence engine (GET /compliance/packs/{id}/report), which evaluates policy-pack controls against this same audit log to generate a per-framework evidence report. Neither page currently links to the other.

Related: