Skip to main content
The Audit Trail is a tamper‑evident log of everything that happens in the workspace: who did what, when, to which object, with what parameters. It’s accessible from the top nav and from the Compliance page.

​
What gets logged

CategoryExamples
AuthenticationLogins, logouts, failed login attempts.
Users & rolesInvitations sent / accepted / revoked, role changes, password resets.
ProjectsCreate, rename, archive, delete, member changes.
DatasetsUpload, edit metadata, branch, lineage updates, deletes.
ScansStart, cancel, finish, error, retry, parameter snapshot.
HealingTrigger, toggle set, output target, completion.
SettingsWorkspace settings, integration credential changes, security policy updates.
Custom rulesCreate / edit / archive / enable / disable per scope.
ReportsReport generation requests, downloads, deletes.
Audit events are append‑only; nothing in Antidote ever rewrites or removes a row from the trail.

​
The Records page

The default view is a filterable, paginated table of events.
FilterValues
ActorAny user in the workspace, or system for automated runs.
Action typecreate, update, delete, scan_started, scan_finished, heal, login, etc.
Object typedataset, scan, project, user, integration, etc.
Date rangeFree‑form, with quick presets (today, last 7 days, this month, last quarter).
SeverityINFO, WARN, CRITICAL, useful for filtering down to security‑relevant rows.
Click any row to open the record detail with the full event payload, a before / after diff, and metadata about who and where.

​
Stats page

The stats view gives you trend analysis at a glance.
  • Counts per actor, per action type, per day.
  • A heat map of activity by hour and weekday.
  • Top actions on the busiest day.
  • “Parameter drift” charts (see below).
Useful for spotting spikes (a misconfigured pipeline burning quota) and gaps (a scheduled scan that quietly stopped firing).

​
Parameter analytics

A specialised view for compliance: see how scan parameters drift over time. Pick an engine, pick a parameter (for example confidence_floor or sensitivity), and the chart shows the value distribution across every run. Auditors care because consistent practice = defensible practice. You can also register custom parameter schemas so the trail captures your own domain‑specific knobs (model_version, clinical_protocol, reviewer_id).

​
Exporting and pushing

  • CSV export of any filtered view, useful for evidence packs.
  • Ingest / import of external audit events from a SIEM or another tool, merged into the unified timeline.
  • Audit webhook that pushes events to your SIEM in real time (see Integrations for setup).

​
Common workflows

  1. Filter by Action type = delete and the date you know it happened.
  2. Click the row to see who triggered it and the parameter snapshot of the deleted object.
  3. Cross‑reference with the parent object’s audit trail (scans and healings against that dataset) to assess the impact.
  1. Filter by Action type = scan_started and the period you’re proving.
  2. Group by Dataset in the stats view to confirm coverage.
  3. CSV‑export and attach to the compliance report.
  1. Filter by Object type = integration and Action type = update.
  2. Cross‑check actor and date with your team’s calendar.
  3. Any unexpected actor here is worth escalating.
The audit trail is the workspace’s source of truth for “what happened”. If you suspect tampering, contact support immediately; the trail is append‑only at the application level and replicated at the storage level.