Shadow enforcement
Nothing on this page was blocked. Enforcement runs in shadow mode across the
whole fleet by decision. Every number here is a counterfactual: the verdict the
scope compiler would have taken, recorded at
LOG_ONLY.What it shows
The scope compiler runs on every endpoint, enabled by default. It builds an authorization scope from the agent’s declared intent, then checks each observed action against it. When an action falls outside that scope it records the verdict it would have applied — and denies nothing. The dashboard reads those records and answers one question: if enforcement were on, what would have happened this week?
Rows group by capability (
fs:read, net:egress), by sensitivity
(s5-credential down to s1-project), or by resource — and are ordered
most-severe first, so a single credential read is never buried under a hundred
routine ones.
Child processes
An action marked child was taken by a process the agent spawned rather than by the agent itself. This is the case an API gateway and an in-process hook cannot see: the parent declared its intent, a descendant did something else, and only kernel-level lineage connects the two.Reading the numbers honestly
- Counts are scoped to a window. The page states how many events it read and how many exist, e.g. “the newest 500 of 812”. Ordering claims apply to that window only.
- An empty result is not a clean result. “No shadow evaluations in this window” means no evaluations reached the cloud — it does not mean every action was in scope. The page distinguishes these two states.
- Unrecognised verdicts are shown, not hidden. If an endpoint reports a verdict this dashboard does not know, it appears in a banner and is counted in the total but not in any column. An endpoint ahead of the dashboard shows up as a stated gap rather than as a silent undercount.