Introduction
Every governance programme reaches the same moment: the controls are on, the incidents are arriving faster than anyone can read them, and the queue has quietly become something people scroll past.
This is the normal outcome of turning controls on, not a sign anything is broken. But an incident list nobody works is worse than no list, because it looks like coverage while providing none.
"Four thousand open incidents is not a security finding. It is a tuning backlog wearing one."
Where to find it
AI Governance > Incidents, then the controls behind them under Controls.
Access to AI Governance is granted through platform roles. Ask your workspace administrator, or see Settings > Governance > Roles for how permissions are assigned.
Why the noise happens
Controls arrive untuned — A framework pack is written for everyone, so it is calibrated for nobody. Its thresholds are a starting point.
Broad coverage multiplies — Applying a policy across the whole estate before tuning it means every agent contributes to the queue at once.
Overlapping policies duplicate — Two policies covering one asset and checking the same thing raise two incidents per event.
Ungraded controls flatten priority — With no severity, nothing sorts, and the whole queue reads as equally urgent.
None of these is a control being wrong. All of them are a control being untuned.
The method
Step 1: Find the noisy controls
Filter the Incidents list by Policy, starting with the policies that have the most open incidents, then open each policy's Controls tab — every control row shows its incident count. The distribution is almost always lopsided — a handful of controls produce the overwhelming majority of the volume.
Those are your entire workload. Fixing the top three usually removes more of the queue than a week of row-by-row triage.
Step 2: Sample honestly
Take ten incidents from the noisiest control and judge each one: real, or false positive. Ten is enough to tell a working control from a broken one.
Mark them accurately as you go — especially the false positives. That status is the only durable record of which controls are misfiring.
Step 3: Choose the right lever
What you change depends on what the sample showed.
What the sample shows | Lever |
Mostly false positives, matches are borderline | Raise the breach threshold on a scale-output check, or raise the detector level. Higher settings mean fewer, more likely findings. |
Real matches, but on traffic that does not matter | Narrow the policy's coverage rather than the control. The control is right; it is pointed at the wrong assets. |
Matches concentrated on one point | Narrow |
Real, but far less serious than the queue implies | Grade the control lower. Nothing goes away; it stops competing with things that matter more. |
Duplicates of another control's findings | Remove the overlap. Two policies checking the same thing on the same assets. |
Genuinely unclear what it is catching | Rewrite the check — and use |
Step 4: Test the change before saving
The control editor can run sample inputs and show what the control would do. Run the false positives you just sampled through it. If they still trip it, the change is not finished.
Step 5: Re-measure after a week
Volume from that control should fall. If it does not, the lever was wrong — most often coverage was the problem rather than the threshold.
What not to do
Do not bulk-close — Clearing the queue without changing anything guarantees it returns by the same date next month, and destroys the false-positive signal on the way.
Do not disable a noisy control and move on — Disabling is fine as a first step while you investigate. Left disabled, it is an uncovered risk nobody is tracking.
Do not tune by deleting incidents — They are the evidence that the control needed tuning.
Do not tune everything at once — Change one lever on one control and measure. Three simultaneous changes leave you unable to say which worked.
What good looks like
The target is not zero incidents. A control that never fires is either perfectly configured or not watching anything, and you cannot tell which.
Aim instead for a queue where every incident is worth a human look, and where the useful metrics are false-positive rate and time-to-triage. Open-incident count measures your tuning backlog, not your risk — and reporting it as a risk metric rewards bulk-closing.
Best Practices
Tune before you widen — Cover a few agents, tune, then extend by rule. Widening first multiplies the noise by your estate.
Grade every control — Severity is what makes a queue sortable rather than a wall.
Book a weekly half-hour — Tuning is maintenance. Untended, the queue only ever grows.
Mark false positives every time — It costs a click and it is the only data that tells you where to work.
Fix at the source — One threshold change beats four hundred individual triages, every time.