Introduction

An incident tells you something matched. Investigating it answers the three questions that follow: was it real, what actually happened around it, and does anything need to change.

The useful property of this section is that an incident already names everything that produced it, so investigation is a short walk rather than a correlation exercise.

Where to find it

AI Governance > Incidents > select an incident

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

What the detail view shows

Opening an incident gives you the violation in context: the content that matched, the control that caught it, the policy that delivered that control, the asset it happened on, the asset's owner, and what was done about it.

Two fields do most of the work in deciding whether it is real:

1. Control violated — Which rule fired. Its check tells you what the system was looking for — and often, immediately, whether this match was sensible.

2. Confidence — The control's configured threshold, not a per-finding score. A control set to Low catches borderline matches, so its incidents deserve more scepticism.

Investigate

Step 1: Assign it

Set Assigned to before you start. An incident being worked with nobody's name on it is one two people investigate and nobody closes.

Step 2: Read the content against the control

Compare what matched with what the control was looking for. Most triage ends here, with one of two conclusions: the control did its job, or the control is too broad.

Step 3: Read the conversation, then the trace

Read the Conversation Snippet, then click View trace to open the session or trace in the agent's Observability tab. This is the step that separates a real finding from a false one — content that looks alarming in isolation is often unremarkable in context, and occasionally the reverse.

Step 4: Check the asset

The Asset card names the agent but does not link to it; open the agent from Agent Registry. Its Overview tells you whether this is an isolated event or one of many, and its Connection type tells you which actions can execute.

On an Observe · Advisory asset every incident records Flagged — the Action column shows what actually happened. Blocked or Masked appears only on Control · Enforced assets.

Step 5: Decide and close

Closing a false positive as Resolved is the most common mistake in this section. It looks the same on the queue and destroys the only signal that tells you which controls need work.

From one incident to a pattern

The question worth asking on every investigation is whether this is one event or an example.

1. Filter by Policy, then search for the control name — If the same control has hundreds of open incidents, you are not looking at an incident. You are looking at a tuning task.

2. Check the Asset column — One agent producing most of a policy's incidents usually means the agent is doing something the policy did not anticipate.

3. Check the Source column — Violations concentrated on Tool Output point at a data source rather than at the agent.

"Investigate the first one properly. After that, investigate the pattern — individually triaging the same false positive four hundred times is not governance."

Important considerations

1. The record is immutable — Tuning a control changes what happens next. It does not rewrite incidents already raised.

2. Severity may be absent — That says the control was never graded, not that the incident is unimportant.

3. Incident content is sensitive — It is, by construction, the material your controls were written to catch. Handle exports accordingly.

4. The Action column is what happened — On Observe · Advisory assets it is always Flagged, whatever the control is set to.