All detections: everything Shield360 found, in one list
Monitor → Detections opens on All detections: everything Shield360 detected in the current project, in one list, with open work first. The other Detections tabs are still there, each with its full tools.
What is in the list
Section titled “What is in the list”| Source | Open until | Quick action |
|---|---|---|
| AI analyst findings | resolved or dismissed | Resolve |
| Behavior findings | resolved | Resolve |
| Policy violations (sensitive data, AI tools, models, sequence policies, prompt injection) | logged events: no status of their own | — |
| Runtime attacks let through in monitor mode | a decision is in force (open again if still reported after it) | decide in the decision queue |
| Vulnerabilities | fixed or accepted (open again if seen after a fix) | Mark fixed |
| Sandbox decisions | logged events | — |
| Web firewall events from Shield360 Edge (let through, blocked, not checked) | logged events | Open the request’s trace |
| Tetragon policy matches on Kubernetes nodes | logged events | Open in Logs |
Allowed policy decisions are not detections, so they are left out.
Find what matters
Section titled “Find what matters”- Open, All, Resolved or Logged events, each with its count. The list starts on Open.
- Sources: turn each source on or off. A source shows hidden by your role or not in your plan instead of a count when you can’t see it, so an empty list never hides something you simply can’t access.
- Severity, a text search, and the time range (24 hours, 7 days or 30 days).
Work a detection
Section titled “Work a detection”Select a row to open its side panel: what the source is, the details, and:
- Open in … goes to its own tab, on that item where the tab can. Web firewall and Tetragon events open Detections → Runtime events, which charts them over time and filters them by rule, action, route, pod or process.
- Resolve or Mark fixed, where the source has a status and your role may change it.
- Open a case opens a case for someone to own, with the detection’s details. A policy violation goes on the case as evidence.
Replay how an event happened
Section titled “Replay how an event happened”A runtime protection or AI security event opens on its own page, Monitor → Detections → event (/detections/event/<id>). The command center’s feed and app panel open it too. The page says, in plain words:
- What happened: the attack or finding, the rule, the decision (blocked or monitored) and the mode.
- Why it was flagged: what the rule looks for, and what its mode does with a match.
- Where in the code: the sink the input reached, the input’s location (such as
query.id), the route, method, framework, language and config version. A masked snippet shows only where the app sends snippets and Settings → Data retention stores content. - App and environment, the time and the event id.
From the page you can open the app, change the rule’s mode on WAF & RASP, open the trace, open a case, and, if your role may change the firewall, block the client at Shield360 Edge.
How it happened replays the event step by step, with play, pause, step, speed and a scrubber:
- This request: each layer in order. Shield360 Edge receiving the request and the rules that matched, the app’s spans for the same trace, the runtime check, the outcome, and Edge’s answer.
- This client’s session: every request from the same client that passed Edge in the 30 minutes either side, so a sequence such as a probe of
/.env, then a decoy path, then a block reads in order. Edge records only the first path segment of each request, never the full URL, query or body.
Runtime protection and AI security events don’t carry a trace id yet, so the page matches the request by app, time, method and route, and labels it best effort. Request bodies, headers and prompts are not captured; the page says so and points to Settings → Data retention.
Reading the event needs the permission of its source: View data protection events for runtime protection, View AI app security for AI security. Edge’s steps and the session also need View data protection events, and the app’s spans need View a request’s contents; without them those parts are left out and the page says why. Full client addresses show only to people who may change the firewall; everyone else sees the client’s network.
Permissions
Section titled “Permissions”There is no separate permission. Each source is read with its own tab’s permission and plan, and each action needs what it needs on its own tab (for example, Manage agent policies to mark a vulnerability fixed, and permission to manage cases to open one).