Stale-policy fail-closed
If the agent cannot reach the cloud for an extended period, what should it do? PermitUSB fails closed past a configurable staleness window. The default is seven days.
The two defensible answers
| Approach | Behavior |
|---|---|
| Trust the cache | Keep enforcing whatever policy was last received. |
| Fail closed | Ignore the cache and default-block everything until connectivity returns. |
How it works
The agent records last_successful_fetch after every 200 or 304 from the cloud. On every device-plug event it checks whether staleness exceeds the configured window. If it does, the engine returns a default-block decision regardless of what the cached policy says. The tray surfaces Policy stale in amber, and a policy_stale tamper event fires, debounced to one per hour to avoid noise.
When the cloud comes back
The first successful fetch resets the staleness clock. The cached policy becomes authoritative again immediately, the tray flips back to healthy, and no manual intervention is needed.
Tuning the window
MaxStalenessDays in the endpoint’s agent.json, default 7. Lower values are stricter; higher values let road-warrior laptops survive longer offline trips without flipping into fail-closed.
Why fail-closed is the right default
A long-offline endpoint has had time for the local situation to change in ways the cached policy cannot anticipate. A thumb drive that was previously allow-listed by serial might have been revoked centrally for a reason. The trust model says the cloud is authoritative, and fail-closed makes that real.
Something missing or wrong here? Tell us. Documentation gaps get filled fast.