> ## Documentation Index
> Fetch the complete documentation index at: https://docs.runlayer.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Incidents
> Triage and remediate grouped security signals from one inbox
Incidents turn the raw stream of security signals — scanner violations, shadow MCP servers, shadow skills, and shadow plugins — into a small set of **grouped, prioritized** items you can **act on**. Related signals roll up into one incident, and each incident offers one-click remediation, so security teams spend their time taking action instead of scrolling audit logs.
Incidents are in **beta** and are available to the **Super Admin**, **Security Admin**, and **IT Admin** [roles](/platform-roles). If you don't see **Incidents** in the sidebar, contact your Runlayer account team to enable it.
***
## How It Works
Incidents do two things: **group** noisy signals into a handful of items, and let you **take action** on each one without leaving the view.
**Grouping** — A background worker (\~1-minute cadence) folds new audit events into persistent incident records. Related signals roll up by a stable key (connector, scanner, violation reason, subtype), counts accumulate over time, and each incident carries aggregated context — top actors, clients, devices, and a trend sparkline. A priority score (severity, volume, recency, and breadth) floats the most important incidents to the top.
**Taking action** — From the inbox or an incident's detail view you triage (resolve, snooze, dismiss) and remediate in one click (tune scanners, block tools or actors, disable connectors, manage shadow assets). Every action is scoped to the incident and enforces the same permission as the underlying change.
Incident counts are cumulative — an incident reflects everything seen since it was first opened, not just the current view window. Triage state is organization-level: resolving an incident resolves it for everyone. Idle incidents with no new activity are eventually cleaned up automatically.
***
## Incident Sources
Each incident belongs to one source bucket, which drives the chips and remediation actions shown:
| Source | Description |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| **Violation** | Security scanner output — ToolGuard, PII detection, hidden ASCII, token masking, AgentGuard, and other scanners flagging tool calls. |
| **Shadow MCP** | An MCP server discovered outside Runlayer management (via [Shadow AI Detect](/shadow-ai/detect)). |
| **Shadow Skill** | A skill installed outside organizational control, grouped by stable content identifier. |
| **Shadow Plugin** | A plugin artifact installed outside Runlayer management. |
***
## The Inbox
Open **Incidents** from the sidebar to see every grouped incident in one ranked list, highest-priority first. Filter by type (Violations, Shadows, Session alerts), severity, scanner, client, server, or user, and sort by priority, recency, age, event volume, or number of users affected. Each row summarizes the incident at a glance: a trend sparkline, what the scanner did (blocked, masked, or allowed), the client involved, and a severity indicator.
***
## Triage
Triage is organization-level — resolving an incident resolves it for everyone — and can be applied to a single incident or in bulk. The inbox has a tab per state (**Unresolved**, **Snoozed**, **Resolved**, **Dismissed**, **All**); these actions move incidents between them:
| Action | Effect |
| ----------------- | ---------------------------------------------------- |
| **Mark resolved** | Mark the incident handled. |
| **Snooze** | Hide for 1 hour, 1 day, or 1 week, then auto-reopen. |
| **Dismiss** | Hide as not actionable. |
| **Clear** | Reset back to unresolved. |
***
## Incident Detail
Open an incident to see its **activity feed** (lifecycle events — created, triaged, remediated — each with actor and timestamp), the **affected users** (top actors), **clients**, and **devices** driving it, and a handful of **sample events** — recent audit log entries that compose the incident.
Top actors are the users and agents most frequently involved in the incident's underlying events, each with a per-actor event count derived from the audit log. Beyond the top list, every incident tracks an exact count of distinct users affected — the inbox can sort by it — and the [Block actors](#violation-incidents) remediation targets these top users and agents directly.
***
## Remediation Actions
Incidents offer one-click remediation scoped to the incident's type and scanner. Each action enforces the same capability as its underlying mutation, so the incident view is never a privilege bypass.
### Violation incidents
Violation actions fall on a spectrum from dialing a noisy scanner down to escalating a real threat:
| Reduce noise | Escalate |
| -------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| **Downgrade to alert** — log matches instead of blocking or masking | **Escalate to block** — block future matches instead of alerting |
| **Mask instead of block** — mask matched content (maskable scanners) | **Block tool** — deny policy for the offending tool on the connector |
| **Disable this PII label** — stop flagging a specific PII label | **Block actors** — deny policies for the incident's top users / agents |
| **Reduce ToolGuard sensitivity** — lower sensitivity one notch | **Disable connector** — take the connector offline entirely |
| **Disable on this connector** — stop running the scanner | |
There's also **Configure scanner settings**, which jumps to the Security Scanners admin page. The available actions are narrowed to what makes sense for the incident's scanner — e.g. PII-label opt-out only appears for PII detection, and per-server tuning is hidden for serverless / local-stdio groups.
### Shadow incidents
| Action | What it does |
| ---------------- | ----------------------------------------------------------------- |
| **Make managed** | Bring the shadow MCP, skill, or plugin under Runlayer management. |
| **Allowlist** | Mark the asset as approved so it stops surfacing. |
| **Block** | Block the shadow asset. |
Remediation actions are idempotent. Re-running an action that's already in effect (e.g. a deny policy that already exists) reports no change rather than creating duplicates.
***
## Auditability
Every incident lifecycle event — creation, triage (resolve / snooze / dismiss / clear), and remediation action — is written to the [audit log](/platform-audit-logs). Lifecycle events (except idle cleanup) also trigger a [Slack notification](/platform-slack-notifications#channel-notifications) if your org has Slack connected.
***
## Related Resources
Security alerts and scanner configuration
Detect and enforce on shadow MCP servers and skills
Allow and deny rules for tools and actors
Full activity and access history