Audit Anomalies

What this report shows

Rule-based detection that scans the unified `audit_log` for known-suspicious patterns:

• Bulk deletes — many rows deleted by one actor in a short window.
• Off-hours admin logins — admin sessions outside normal business hours.
• Admin permission grants — someone gained admin or service-role permissions.
• Mass data exports — exports that pulled a large amount of data.

Click any row to drill into the underlying audit event in the Audit Log viewer for full context.

How to read it

• Each row is one anomaly hit. Severity is set by the rule that triggered.
• Actor — the user / service that performed the action.
• When — timestamp of the underlying audit event.
• Rule — which detection rule flagged this. Useful for tuning thresholds.

Not every anomaly is malicious — off-hours logins often happen because someone is on a different timezone or working late. Investigate; don't accuse.

Common questions

• Why is the same actor showing up repeatedly? Likely a legitimate pattern (admin doing housekeeping). Tune the rule threshold if it's noisy.
• Why didn't a known suspicious action appear? Either the rule doesn't have a detector for that pattern yet, or the underlying audit event has a different type/category than the rule looks for.
• What's a "bulk delete" threshold? Configured per environment. Check the rule definition for the exact count and time window.

What to do if numbers look wrong

1. Click into the suspicious row — read the audit log payload for the surrounding context (URL, IP, request ID).
2. Confirm the actor identity — sometimes a service-role action looks like a user but isn't.
3. If false-positives are flooding the page, look at tuning the rule threshold; if the rule misses real anomalies, add a new rule.