Audit log is append-only (tamper-resistant)

GDPR Article 5(2) accountability requires that compliance records be trustworthy — a mutable audit log provides no assurance because any entry could have been silently modified after the fact. CWE-472 (External Control of Assumed-Immutable Web Parameter) and CWE-778 (Insufficient Logging) both apply when audit records can be retroactively altered. NIST AU-9 explicitly requires protection of audit information from unauthorized modification and deletion. An audit log that a rogue service account or a poorly-reviewed migration can UPDATE or DELETE is worthless as legal evidence — it cannot prove what actually happened, only what the log currently says.

Enforce immutability at the database level — application-layer checks alone are insufficient because any service with write access can bypass them:

-- Option 1: PostgreSQL RULE (blocks UPDATE and DELETE at the SQL parser level)
CREATE RULE audit_log_no_update AS ON UPDATE TO audit_log DO INSTEAD NOTHING;
CREATE RULE audit_log_no_delete AS ON DELETE TO audit_log DO INSTEAD NOTHING;

-- Option 2: Row Level Security (permits only INSERT for the application role)
ALTER TABLE audit_log ENABLE ROW LEVEL SECURITY;
CREATE POLICY audit_log_insert_only ON audit_log
  FOR INSERT TO app_role WITH CHECK (true);
-- No SELECT/UPDATE/DELETE policies for app_role

After adding the constraint, search all migrations in supabase/migrations/ for any UPDATE audit_log or DELETE FROM audit_log statements and remove them. Treat any future PR that adds such a statement as a critical security review item.