Alerts
The platform records a great deal — a fail-open approval, a containment, a tool surface changing under a running agent. Governance → Alerts is where it tells you about the ones worth a person's attention, and whether anyone was notified.
| Action | Role needed |
|---|---|
| View alerts and the number of rules enabled | Viewer and above |
| Acknowledge, Resolve | Editor and above |
| Install the default alert rules | Admin |
| Create, edit, disable or delete rules | Admin, through the API |
The page
Use the status filter to show Open (the default), Acknowledged, Resolved or All alerts, and Refresh to reload.
The header line shows how many alerts are open, broken down by severity (critical, warning, info), and how many rules are enabled. With nothing open you'll see "Nothing open. N rules watching."
If the page says No alert rules are configured, so nothing here would ever fire, an empty inbox means nothing — not that nothing went wrong. A project Admin can click Install them to install the default rules.
Each alert shows:
| Item | Meaning |
|---|---|
| Title and summary | What happened. |
| Shape | categorical, threshold, first seen or absence — see below. |
| Severity | critical, warning or info. Critical alerts have a red border. |
| ×N | The same finding recurred N times. Repeats of an open finding for the same subject within 24 hours fold into one alert rather than piling up. |
| Subject | The agent, server, identity or other subject the finding is about. |
| Enforcement point | Where the decision was made, when relevant. |
| Reason code | The reason code that triggered it, when relevant. |
| Quiet for | For an absence alert, how many hours the point has been silent. |
| Count | For a threshold alert, how many occurrences in how many minutes. |
| Delivery | Whether the notification was sent — see below. |
Acknowledge and resolve
- Acknowledge records that someone has seen the alert. It moves to Acknowledged but isn't closed.
- Resolve closes it. If the same finding happens again, it reopens as a new occurrence.
Alert shapes
| Shape | Fires when |
|---|---|
| categorical | It happened at all. Always worth telling somebody. |
| threshold | Enough of the same thing happened for one subject inside a time window. |
| first seen | A reason code this project has never produced before appears. |
| absence | An enforcement point that was producing decisions has stopped. A silent enforcement point and a quiet one look identical from everywhere else, so this is the only thing that catches a control that stopped running. |
Default rules
Install them adds these rules to the project. Installing is safe to repeat and never overwrites a rule you've edited.
| Rule | Shape | Severity | Fires on |
|---|---|---|---|
| Human oversight bypassed | categorical | critical | An approval was granted without a person because the approval machinery was unavailable (discharged_auto_approved_fail_open). |
| Approval degraded | categorical | warning | An approval timed out, or had no channel to reach a person (discharged_timed_out, discharged_no_channel). |
| Decision point unavailable | categorical | critical | The policy engine couldn't be reached and calls failed closed (denied_pdp_unavailable, denied_no_caller_context). |
| Containment fired | categorical | critical | An agent identity, MCP server or tenant was killed or quarantined. |
| Tool surface changed | categorical | warning | An MCP server changed the tools it advertises. Its tools are refused until the new surface is reviewed. |
| Evidence chain does not verify | categorical | critical | The hash-chained decision trail failed verification. |
| A reason code never seen here before | first seen | warning | A decision carried a reason code this project has never produced. |
| An enforcement point went quiet | absence | critical | A point that was producing decisions has produced none for 24 hours. |
Notifications
The default rules have no notification channel, so their alerts show Delivery as skipped — the finding is recorded, but nothing is sent. To be notified, an Admin can give a rule a webhook through the API (see Governance API).
| Delivery state | Meaning |
|---|---|
| pending | Waiting to be sent. The finding is already recorded either way. |
| delivered | Sent to the rule's channel. |
| failed | Couldn't be sent. The finding stands; only the notification was lost. The alert shows the number of attempts and the error. |
| skipped | The rule has no channel, so nothing was sent. |
An alert is always saved before delivery is attempted, and delivery never sits in the path of a tool call, so a broken webhook costs you a notification, never the record. Failed deliveries are retried, up to five attempts.
Related
- Policy — the decisions alerts are raised from
- Reason codes
- MCP Gateway — containment and tool-surface review