Self-protection
Enforcement is kernel-mode on current agents: a Microsoft-signed filter driver sits on the USB stack and blocks devices below anything reachable from Device Manager or an elevated PowerShell session. User-mode enforcement runs underneath as a second layer, and is the only layer on endpoints without the driver.
Kernel-mode driver
The driver enforces policy from early boot using a locally cached snapshot, before the Windows service starts, so there is no window where a blocked device works because the agent has not come up yet. Blocking happens on the bus: re-enabling a device in Device Manager does not restore access, because the driver denies it beneath that layer. A kill switch, per endpoint or workspace-wide, stands the driver down to user-mode enforcement. It takes effect within minutes and survives a restart.
Service ACL
On install, the service security descriptor denies STOP, PAUSE and CHANGE_CONFIG to non-administrators. A regular user cannot stop the agent service from a non-elevated PowerShell.
Watchdog
About every 30 seconds the agent walks its known set of disabled USB devices through Win32_PnPEntity. For each device the agent itself previously disabled, if it is now enabled, the watchdog re-disables it and emits a watchdog_re_disable tamper event.
Stale-policy fail-closed
If the agent cannot reach the cloud for longer than the configured staleness window, seven days by default, it ignores its cached policy and falls back to default block. The tray shows Policy stale in amber.
What this catches
- Casual users running Stop-Service from a normal terminal
- Admins re-enabling a blocked device in Device Manager: denied at the bus on kernel-enforced endpoints, re-disabled within 30 seconds with a tamper event on user-mode endpoints
- Refresh-token replay attempts, caught by the rotation counter, which locks the tenant and logs a tamper event
- Long offline periods used to outwait enforcement, handled by stale-policy default block
- Loss of kernel enforcement: if the driver is removed on an endpoint configured for kernel mode, the agent raises an error-severity security event (event ID 4002)
What it does not catch
An elevated admin uninstalling the agent and driver entirely. The uninstall automatically decommissions the endpoint, records a security event, and can raise an opt-in Endpoint decommissioned alert, because an unexpected uninstall is worth investigating.
Alerting on tamper
Tamper events surface in the dashboard on the events view filtered to tamper, with severity badges. Configure email or webhook alerts on the watchdog_re_disable, refresh_token_replay and policy_stale kinds for proactive notification.
Something missing or wrong here? Tell us. Documentation gaps get filled fast.