One timeline of every policy hit across managed chat, inspected browser traffic, the extension, endpoint agents and document analysis.

All Detections is the one table that answers "what did the gateway catch, anywhere". It merges five stores — managed chat, inspected proxy traffic, browser-extension events, endpoint-agent and Claude Code reports, and document analyses — into a single timeline, so you do not have to visit a page per capture point.

What do I need?

Licence: Any
Role: admin_userviewer

Prerequisites

At least one capture point is live: managed chat, an inspecting SWG or inline proxy, the browser extension, an enrolled endpoint agent, or a document analysis.
You are signed in as admin_user, superadmin, viewer or auditor. An auditor and a viewer read the page; neither sees raw message content.

Only policy decisions are stored. Clean traffic that produced no finding is not persisted by most channels, so an empty table is not proof that nothing happened — widen Traffic before drawing that conclusion.

Screenshot pendingAll Detections with four verdict stat tiles, the filter bar and the merged detections table/assets/screenshots/all-detections@0.4.png

Find the detections you care about

Open the page

Select Detection & Filtering → All Detections.

Four tiles summarise the current filter — Total detections, Masked, Rejected, Flagged — and the table below shows 25 rows a page. The filter bar's right edge reads Auto-refresh every 30 s.

Pick the capture point

Set Source to one of Chat detections, Browser inspection, Extension events, Claude Code, Endpoint agents, Image analysis or Document analysis.

The tiles follow the filter, so the KPI numbers always describe the rows in the table.

Narrow by what was scanned

Set Type to Text, Files, Images or Documents.

Every row resolves to exactly one type, so this filter gates whole streams or type sets and never silently drops individual rows.

Choose the side of the exchange

Set Filtering to Input (prompt), Output (response) or Input & output.

Input rows are the ones input filters govern; output rows are the response side. The extension inspects the outbound request only, so it is excluded from an output-only query rather than returning nothing.

Choose the verdict and the traffic

Set Action to Masked, Rejected or Flagged, and Traffic to Detections only (the default) or Include clean traffic.

Verdict filters are type sets, so Rejected includes a blocked file upload as well as a blocked message.

Set the time window

Set Window to Last hour, Last 24h, Last 7 days, Last 30 days, Last 90 days or All time.

The default is the last 24 hours. The windows match the AI Usage report's own, so a drill-down between the two pages lines up.

Read one detection

Open the row

Select the row, or its View details button.

The drawer names the channel and describes it — for example Policy hit on inspected browser/SWG traffic. — then lists the evidence that stream actually stores.

Read the evidence for that stream

Look at Matched Entities and the channel-specific fields.

What exists differs by capture point, and the drawer says so rather than showing an empty panel. An inspection row carries the entity type, action, confidence, detector, filter and the mask placeholder — never the detected text. A document row carries per-entity page numbers and no value at all.

Open the audit view

Select Open audit view.

The Audit view answers why the decision was made: What fired, What CID did, Regulations this touches, Controls this falls under, Which policy layer selected this, Where and when, Who, Review, and Where each answer came from.

Judge the record, not just the verdict

Read Record completeness.

The score is weighted over 14 audit fields, and each missing field carries a reason in product language. Compare a score only against its own denominator.

What the audit view will not claim

No raw values, ever. Types, counts, detectors and actions only. The payload states it as Categories and counts only — this view never reads the matched text.
A rule renamed or deleted since the detection is shown as no longer exists rather than dropped, and the note says the other possibility: the capture point may have recorded the detector rather than the rule.
Control posture is present tense. The view says so — nothing in the product records a control's state per event.
Regulation mappings are resolved as of the event's own timestamp from an append-only ledger, so retargeting a mapping later does not rewrite history. Events older than the ledger resolve from the live table and say so.
Which policy layer selected this reports whether the tenant and group layers were consulted on that capture path. Managed chat responses and visual-mode document analysis do not consult them, and the rung notes repeat that in words.

Export the current view

Export

Select CSV in the page header.

The export carries the rows the current filters describe, and its header block restates the filter — source, verdict, direction, type and whether clean traffic was included — so a downloaded file cannot be read out of context.

Who sees message content

Role	Sees
`superadmin`	Everything, including Captured Prompt and the page URL on extension rows
`admin_user`	Every field except captured content; the drawer shows Captured content exists for this event but is visible to superadmin only.
`auditor`	The same, and matched values on chat and extension rows are replaced by the masked form or the entity-type placeholder, with Matched values are hidden for your role — the entity type is shown instead.
`viewer`	Reads the page; every mutating request is refused

Warning

The capability all_detections.view_content appears in the access-control inventory, but the capability model runs in shadow mode and enforces nothing today. The live gate is a literal role check for superadmin — granting that capability to another role changes nothing.

Rows that carry no tenant — inspection events where attribution failed and no default inspection tenant is set — belong to the appliance. They are shown to admin_user and to global readers, deliberately, because hiding them read as lost enforcement. They never appear inside an explicit per-tenant drill-down.

Fields reference

Table columns

Column	Shows
Time	When the detection occurred
Source	The capture channel: Chat, Browser, Claude Code, Endpoint Agent, Extension, Image Analysis, Document Analysis
Type	What was scanned — Text, File, Image or Document
Where	The hostname, path or session the hit came from
Who	The attributed person, corrected against the tenant record where one resolves
Action	The verdict applied: Masked, Rejected or Flagged
Detected	The entity or violation categories
Count	How many entities the row carries
Latency	Inspection latency, or inline where the check was part of the request

Filters

Filter	Values
Source	The seven capture channels. The parent `inspection` stream is not offered in the UI; it stays valid on the API
Type	Text, Files, Images, Documents
Filtering	Input & output, Input (prompt), Output (response)
Action	All actions, Masked, Rejected, Flagged
Traffic	Detections only, Include clean traffic
Window	Last hour, 24h, 7 days, 30 days, 90 days, All time
User: chip	Present when the table is scoped to one person; the × clears it

Verify

The four tiles and the table agree — the tiles are computed with the same filters, including Traffic.
Trigger a detection you control: send a prompt through AI Chat that a MASK rule catches. Within the auto-refresh interval a new row appears with Source Chat and Action Masked; the underlying event type is MESSAGE_MASKED.
The feed's rows are exactly the event types the registry classifies as detections — MESSAGE_BLOCKED, MESSAGE_MASKED, PII_DETECTED, FILE_UPLOAD_BLOCKED, FILE_UPLOAD_REDACTED, RESPONSE_MASKED, RESPONSE_PII_FLAGGED, IMAGE_ANALYSIS_DETECTION, HELP_INPUT_MASKED and HELP_INPUT_FLAGGED — plus the chat, extension and document tables. See the generated event type reference for the full classification.

If it fails

No detections match the selected filters. — widen Window, or set Traffic to Include clean traffic. The default view is detections only.
The pager reads detections+ — narrow the time window or filters to reach older rows — the merge hit its key ceiling (ALL_DETECTIONS_MAX_MERGE_KEYS, 20000 by default), so the advertised total is a floor and the oldest rows are out of reach. Narrow the window or the filters rather than paging further.
A row you expected is missing and Source is Extension events — extension rows whose verdict is ALLOW are clean traffic and are excluded, matching the extension's own views.
Opening a detection returns not found — the id is outside your tenant scope, names an unknown stream, or names an event type the registry does not classify as a detection. The endpoint never confirms that a row you cannot read exists.
This channel has no review workflow. in the audit view — review state is recorded for managed chat only. It is not a rejection and not an unreviewed detection.
No regulation in this deployment maps to these entity types. — the detection carried entity types no mapping covers. The note beside it says which of the three reasons applies.

Note

The in-product help describes an Analyse action that hands the current filtered view to the risk analyst. No such control exists on this page in 0.4 — start an analysis from the Risk Analysis pages instead.

Next steps

Security filters — change the rule behind a verdict you disagree with.
Browser-traffic inspection — fix attribution when Who is empty on proxy rows.
Event logs — the full audit trail, including the events this feed does not classify as detections.

Read the All Detections feed