Docs
AI incidents
One queue instead of three, across security, performance and operations. Three sources feed it and each case says which it came from: a durable security finding from the session-signals detectors, a correlated production incident blamed to a change, and a runtime containment event when the gate holds a dangerous action. Each case carries a status, an owner, a deadline, and the attribution behind it (which session, which prompt, which person) with its confidence stated rather than implied.
Where to find it
- Localhost:
/agent-incidents.html - API:
GET /api/ai-incidents(queue),/detail,/metrics,POST /api/ai-incidents/assign,/lessonand/lesson/draft - Sidebar: Guard, then AI incidents
- Hosted: the approve and deny console and the cross-machine view live at
/team/agent-incidents
What it does for you
Built vs. planned
The queue, the fold, the case detail with its chain and timeline, assignment, the lifecycle actions and the lesson draft all ship today, LLM-free. Measured time to acknowledge and time to resolve are computed but refuse to report below a sample floor of eight resolved cases, so a small queue reads as not enough yet rather than a number built from two rows. On the hosted side, containment records the decision and requests revocation; the desktop daemon or broker performs it and fails closed, so nothing reports contained when a leg did not complete. An attested decision proves a human approved, not that the model obeyed.
Last updated