Security
Retention / pruning
Run the auth-failures retention prune and see the run recorded in the audit trail. This is the only retention mechanism that exists today -- no other table has a prune path -- and the trail below is the same unified audit timeline shown under its own sub-item.
Audit trail
Grant and signing-key issuance/revocation, quota-breach propagations, and auth-failures retention prune runs, unified and newest-first (sql/063, extended by sql/088 and sql/089). Every row carries a computed severity (grant of owner/ administrator and a retention prune are Warning, everything else Info) -- a fixed, typed rule per event_type, not an arbitrary label. Click a row for its full detail. Some rows show a blank Actor: neither a grant revocation nor a quota-breach propagation records WHO acted, anywhere in the schema today -- a real, disclosed gap, not a rendering bug (see 088's own comment).
Loading…
Retention prune
Deletes auth_failures rows older than the retention window below and records the run permanently (auth_failures_pruning_log) -- shows up in the audit trail above as "Auth-failures retention prune." Owner at your root node only. Preview first to see the real row count and oldest row before anything is deleted -- a genuine dry run (preview_auth_failures_prune, sql/179), not an estimate.
Blocker: a configurable retention policy per data type, and a legal-hold override, do not exist for auth_failures -- and device compliance hold is a genuinely different mechanism, not reusable here.
Per-data-type retention policy -- auth_failures is the only table with a real prune path (prune_auth_failures, sql/064) at all; nothing else in this schema (security_events' own source tables, security_anomalies, audit_log) has a retention window or a prune function. "Configurable per data type" would mean building that mechanism for each of those tables from scratch -- a real, separate piece of work this task's scope does not cover, not a small extension of what exists.
Legal hold override -- checked directly before assuming these were the same concern: sql/152's compliance_hold (devices.compliance_hold, set via set_compliance_hold()) blocks a specific device from being decommissioned/erased. It is a column on devices, keyed by device id, with no relationship at all to auth_failures rows (which carry no device, tenant, or identity attribution -- see sql/049's own header comment). There is no way to "extend" a device-scoped hold to cover an anonymous, platform-wide log table; the two are different concerns (a specific asset's lifecycle vs. a retention window over an unattributed log), and building a real legal hold for auth_failures would mean a new, separate mechanism -- not invented here.