Introduction

An incident is the record of a control finding something. It is where governance stops being configuration and becomes a queue somebody has to work.

It is also the section that decides whether your programme is credible. A tuned incident list is evidence; an untriaged one of several thousand is a liability with a timestamp on every row.

Where to find it

AI Governance > Incidents

Also per-asset on an agent's or model's Incidents tab, and per-policy on a policy's.

Access to AI Governance is granted through platform roles. Ask your workspace administrator, or see Settings > Governance > Roles for how permissions are assigned.

What raises an incident

One thing: a control matching on an asset a policy covers. Every incident therefore names the whole chain that produced it — the asset, the policy, the control, and the action taken.

That is what makes the list workable. You are never guessing why something appeared.

The Incidents table

The list shows 20 incidents per page, newest first. Filter it by Status, Action and Policy, and by Detected date range; search matches the incident text. There is no filter by control, asset or source, and no grouping.

Refer: Incident titles are the offending content, so the list can contain exactly the sensitive data your controls were written to catch. Treat access to Incidents as access to that data.

The incident drawer

Selecting a row opens a drawer with the action banner, then Asset, Asset type, Check type, Confidence, Severity, Source, User and Detected. A Control violated card links to the control and its policy. Below it, Triage holds the status, the assignee (including Unassigned) and notes.

The page URL includes ?incidentId=, so you can share a link that opens the drawer on that incident.

The four statuses

False Positive is the most valuable of the four and the least used. Resolving a false positive as Resolved loses the signal that a control needs tuning — and tuning is the only thing that stops the queue growing. Mark it honestly.

Severity and confidence

Two different questions, easy to conflate.

1. Severity — If this is real, how much does it matter? Set by the control's grading. Frequently absent — see Severity & How It Is Assigned.

2. Confidence — Low, Medium or High, taken from the control's confidence threshold setting. Controls without a threshold record High. It describes how the control was configured, not how sure the system is about one finding.

Read confidence as a property of the control: a Low threshold catches borderline matches and produces more false positives.

On volume

Incident counts in the thousands are normal on first adoption, and they are not a measure of risk. They are a measure of how many controls are running untuned against real traffic.

Treat a large number as a tuning backlog rather than a security finding. The work is to identify the controls producing most of it and fix them at the source. See Tuning Policy Noise.

Best Practices

1. Assign before you investigate — An unassigned incident is one everybody assumes somebody else has.

2. Mark false positives as false positives — It is the only signal that distinguishes a bad control from a busy one.

3. Work by control, not by row — Filter by Policy, then open the policy's Controls tab, where each control shows its incident count. Fixing the top one usually removes more of the queue than a day of individual triage.

4. Restrict access deliberately — The list contains the content your controls caught.

5. Do not report open-incident count as a metric — Report false-positive rate and time-to-triage. Those measure the programme; the raw count measures your tuning backlog.