Investigating incidents and building custom detectors from real findings

The Incidents dashboard

Every prompt scanned by the browser extension, desktop agent, CLI, or MCP layer that produces a finding lands in one place: app.zeuslock.ai/incidents. This is where you spend most of your time as an operator. The dashboard is built to take you from "something fired in the last hour" to a closed ticket in a few clicks.

Across the top of the table you have the filter bar. Each filter is multi-select and stacks with the others:

• Date range — last 15 minutes through last 90 days, plus a custom window for audits.
• Severity — Critical, High, Medium, Low. Severity is set by the detector that fired, not by the user.
• Finding type — every detector category: api_key, credit_card, IBAN, password, JWT, private_key, source_code, NIR, and so on.
• User — by email or by group synced from SCIM.
• Destination — ChatGPT, Claude, Gemini, Copilot, Mistral, Perplexity, DeepSeek, or any custom domain caught by Universal mode.
• Status — Open, In Review, Resolved, Dismissed.

Sort by timestamp (default), severity, user, or destination. The active filter set is encoded in the URL, so you can share a triage view with another analyst by copying the link.

Reading an incident card

Each row in the list is a compact card with everything you need to decide whether to open it:

• User identity and group.
• Browser or desktop client and OS.
• Source URL the prompt was about to leave to (e.g. chat.openai.com).
• A coloured severity badge.
• Finding-type chips — one per detector that fired on the same prompt.
• A redacted preview of the prompt. Sensitive segments are masked at render time; the raw value is never sent to your browser.
• Timestamp in your operator timezone.
• Action taken: Monitor, Anonymize, or Block.

Opening an incident

Click a card to open the full incident view. You get the complete timeline of what happened, in order:

1. Browser-side detection — the regex layer fired, with the offset(s) inside the prompt and the matched detector ID.
2. Optional ML confirmation — if the policy escalated to the EU-hosted NER model, you see the confidence score returned and the model version.
3. Action — what the client did: passed through, anonymised in place, or blocked with a user-visible banner.

Below the timeline you have the original detection rule (so you can see exactly what matched), the confidence score from the ML pass, and the character-level positions of each finding inside the prompt. Hover a position to highlight it in the redacted preview.

Triage workflow

Treat every incident as a small ticket. The workflow is deliberately short:

1. Open the incident and read the timeline.
2. Decide: real finding or false positive. Click Confirm or Dismiss as false positive. Dismissals feed the detector tuning queue we review weekly.
3. If it is real and needs follow-up, assign it to a team member from the Assignee dropdown. Assignees are notified by email and (if configured) by Slack DM.
4. Move it through statuses: Open → In Review → Resolved. Status changes are written to the audit log with actor, timestamp, and reason.

We recommend a daily 15-minute pass on Critical and High, and a weekly sweep on Medium. Low rarely needs human review unless a pattern shows up in reports.

Build a custom detector from an incident

The most valuable thing you can do in this dashboard is convert a recurring real finding into a detector. The classic case: you keep seeing your own internal customer IDs (something like CUS-12345) leak into ChatGPT prompts. A generic detector will not catch that — but you can build one in under a minute.

1. Open an incident that contains the recurring identifier.
2. In the right-hand panel, click Create detector from this finding.
3. Zeuslock proposes a regex (e.g. \bCUS-\d{5}\b), a suggested severity, and a suggested action.
4. Edit the regex if needed, set a finding type name (e.g. internal_customer_id), and pick the action: Monitor, Anonymize, or Block.
5. Click Backtest against last 30 days. Zeuslock re-runs the candidate regex against the last 30 days of incidents (and a sampled slice of clean prompts) and tells you how many extra alerts it would have produced and on which users.
6. If the noise level is acceptable, click Activate. The detector ships to every browser extension and desktop agent on the next policy heartbeat (under 60 seconds).

Tags, evidence, watch lists, SIEM

Tagging incidents

Free-text tags on an incident survive into reports and exports. Use them for things the schema does not capture: vendor-mistake, rgpd-art-32, q2-review. Tags are how you make monthly reviews searchable months later.

Exporting evidence

Two export shapes, picked from the toolbar:

• Export → CSV on a filtered list — one row per incident, with user, destination, finding types, action, severity, timestamps, tags, assignee. This is what auditors usually want.
• Export → PDF on a single incident — the timeline, the rule, the redacted prompt, the action, and the audit trail of assignment and status changes. This is the artifact you attach to an internal investigation ticket.

Watch lists

Under Incidents → Watch lists, pin specific users, groups, or destinations. Pinned entities surface at the top of the dashboard, can be wired to email or Slack alerts, and get their own dedicated KPI tile. Typical uses: pin the finance team during quarter-close, pin deepseek.com while you finalise a shadow-AI ruling, pin a contractor for the duration of an engagement.

Sending incidents to your SIEM

Every incident can be pushed to your SIEM in real time. A webhook fires per incident with a JSON payload, signed with HMAC-SHA256 so your collector can verify it actually came from Zeuslock. For payload shape, retry semantics, and signature verification, see Webhooks and SIEM integration. Splunk HEC, Microsoft Sentinel, and Elastic all consume this without custom code.

What good triage looks like

You will know the dashboard is working when three things are true: your queue of Open incidents stays under a day old, your false-positive rate per detector trends down week over week, and the bulk of incidents flow through Anonymize rather than Block. That last point is the goal — your users keep working, and your sensitive data stays where it belongs.