Endpoint detail and applied policy
The per-host modal reached from the endpoint list: whether a machine actually applied the policy the server built for it, its package inventory and KEV-flagged findings, and the quick actions available from there.
The endpoint list tells you whether a machine is reporting at all — see The endpoint list and endpoint health. This wave added a View details row action on that list, opening a per-host modal that answers a narrower and newer question: did this specific machine actually apply the policy the server built for it, and what does it look like from a posture and response standpoint. This article covers what that modal shows and what its three quick actions genuinely do.
Applied policy: a hash, not a bare version number
A sensor confirms which policy bundle it actually verified and applied by reporting back a small telemetry event once per successfully applied bundle — never on every heartbeat. The platform stores what it confirmed against that sensor's record, and the endpoint detail modal shows it as "applied policy version" and "applied policy at".
The bundle offered-versus-applied mismatch badge
The modal compares the host's confirmed content hash against the content hash of the latest bundle the server has actually built for that sensor, and shows one of three states:
| State | Meaning |
|---|---|
| Matched | The host's confirmed hash equals the latest bundle's content hash. It is running what the server most recently built for it. |
| Mismatched | Both sides have reported something, and they genuinely disagree — the host has not yet fetched and confirmed the latest bundle. |
| Unknown | Deliberately not the same as mismatched. Shown when either side has never been observed — a sensor that has never reported a policy_applied event, or a tenant with no bundle history for that sensor yet. A host that has never confirmed anything has not actually disagreed with anything, so it is shown as unknown rather than as a false alarm. |
A mismatched badge on a host that should be online is the signal worth acting on — it usually means the host has not checked in for its bundle recently, or its last check-in failed verification. A matched badge confirms the loop closed end to end: the policy you configured, resolved through host-group precedence, signed, delivered, verified and applied.
Package inventory and KEV-flagged findings
The modal also shows this host's package inventory and its vulnerability findings, with a CISA-KEV pill on any finding flagged as actively exploited — both fetched lazily when you open the modal rather than for every row in the endpoint list. See Exposure: vulnerabilities and posture for what feeds this and how the KEV flag is weighted in your posture score.
Quick actions
- Isolate — raises the same
isolateresponse ticket the platform's other isolation controls raise, through the same confirm-gated dialog. See Isolating a machine before you use it for the first time. - Run a script — a link to the response-scripts page, where you pick this host through the same search-first picker used there. See Response scripts and run-script tickets — and read its provisioning caveat before assuming a script will actually run.
- Preview effective policy — resolves and signs the CURRENT effective policy for this host, exactly what it would receive on its next scheduled check-in, without creating a new bundle version or pushing anything.
What to do next
- Open a host's detail view after any policy change you make and confirm the mismatch badge reads matched once it has had time to check in.
- Read The signed policy bundle for the full mechanism this modal is reporting on.
- Read The endpoint list and endpoint health for the broader online/stale picture this modal sits alongside.