Oversight & Audit-Trail Tampering
highOversightDefinition
The flight recorder and the alarms can themselves be attacked. If logs can be erased or rewritten, fake entries slipped in, or the monitors quietly evaded, the one record you'd rely on to notice and investigate an incident is no longer trustworthy.
Where it attaches
The system components this risk arises at.
Detection signals
- ▸ Gaps, resets, or out-of-order timestamps in audit logs
- ▸ Log entries whose content breaks dashboards/parsers (injected markup or control chars)
- ▸ Anomaly-detector or eval scores that flatline or never trip on known-bad input
- ▸ Disabled, downgraded, or unusually-permissioned logging/monitoring config
Controls & guardrails that address this
3Grouped by control function, with the AI lifecycle stage(s) to apply each and the other risks it addresses. Filter by control category below.
Recording everything — questions, documents fetched, actions taken — so you can investigate when something goes wrong.
Live dashboards and alarms that notice unusual behaviour — spikes in errors, weird actions, sudden data access.
The organisational habits around the AI: assessing risks before launch, actively trying to break it, and having a plan for when something goes wrong.
Framework mappings
- AML.T0015 Evade ML Model
- AML.T0031 Erode ML Model Integrity
- MEASURE 2.7
- MANAGE 4.1
Real-world cases
1Actual published events that illustrate this risk — click through for the writeup and sources.
Browse all real-world cases →