Audit Log

Every state-changing action through the application is captured automatically into an append-only, DB-sealed audit trail, no configuration required to begin collection. Read-only queries are excluded by design.

Record Fields

FieldContents
WhenAction timestamp
UserActing account email (system for automated actions)
ActionOperation code (e.g. CREATE_LOGIN, UPDATE_CONNECTION, DELETE_SCRIPT)
EntityType and id of the affected record
Before / AfterPre- and post-change values; password, token, secret, apiKey, mfaToken and peers redacted before write
IP addressRequest source

Integrity Model

Each row is sealed by a database trigger into a SHA-256 hash chain (monotonic sequence + prior-hash linkage). UPDATE/DELETE are refused at the table level; the only sanctioned removal is the retention purge, which trims the oldest tail while keeping the surviving chain verifiable. Verify end-to-end via GET /api/db-devops/audit/integrity (Enterprise), which returns { valid, brokenSeq, total } and pinpoints the first broken sequence, detecting even direct superuser edits. See Best Practices, Audit & Compliance for the full scheme and the superuser caveat.

Viewing

Open Administration → Audit Log in the Database DevOps tool (also reachable via the ⌘K palette). The view requires an administrator role and an Enterprise license. Collection is unconditional regardless of tier, pre-Enterprise data is recorded and surfaces once Enterprise is activated.

Because this is a database IDE, you can also attach a connection to the application's own metadata database and query audit_logs directly from the editor for ad-hoc forensics.

Retention

Governed by Audit log retention (Settings → Audit), default 90 days, enforced by the controlled purge function. Set it to your compliance window and archive the tail off-box before purge for long-horizon retention.