Network allowlist

The endpoint agent

The Windows agent runs as a LocalSystem service and talks to two destinations, both HTTPS on 443:

Everything routine, meaning enrollment, policy fetches, event uploads and tamper reports, goes through the API on the permitusb.com domain. The one exception is agent auto-update: the API hands the agent a short-lived signed URL and the installer download comes from the storage host above. Block that host and the agent enrolls, enforces and reports normally, but every upgrade you approve fails visibly at the download step.

The check-in channel

Since agent 1.0.59, each endpoint also holds one long-lived outbound HTTPS connection to nudge.permitusb.com on port 443. That is what makes the dashboard Check in now button work in seconds: the connection carries nothing but a check-in signal, and the agent responds by running its usual policy fetch. It is covered by the wildcard entry above; if you allowlist specific hosts, add it explicitly.

Two proxy notes. If this host is blocked, nothing else degrades: enforcement, events and the regular schedule are unaffected, and the button honestly reports the endpoint as not connected. And proxies that cap or idle-out long-lived connections are fine, because the connection carries a keepalive every 25 seconds and the agent reconnects automatically.

Identity-aware proxies and secure web gateways

If your egress runs through an identity-aware proxy or SWG, you must add a destination-based authentication bypass for both destinations above.

Exempting *.permitusb.com from user authentication on the proxy fixes this permanently. It is the same treatment every machine-context agent needs on these platforms, including EDR, RMM and backup.

FortiGate example

Create FQDN address objects for both destinations, then a firewall policy to them on HTTPS with no source user or FSSO group requirement and captive portal disabled, ordered above your authentication-required outbound policy, because FortiGate matches top-down.

Then move the new policy above the FSSO policy. Wildcard FQDN in policy needs FortiOS 6.4 or later; on older builds use the specific hosts agent.permitusb.com and nudge.permitusb.com plus your API host. Use certificate inspection rather than deep inspection on this policy so TLS interception does not interfere with the agent.

The dashboard

Admins reach the dashboard from a normal browser, where authentication runs through Supabase. If admins manage PermitUSB from inside the same restricted network, their browsers additionally need the same two hosts, including WebSocket to the Supabase host.

This is a browser and human path, not the agent path. A blocked Supabase host here fails loudly and immediately, since the admin cannot sign in, rather than causing the silent agent drift above. Allowlisting it avoids a confusing first-login experience. The Supabase host is the same for every customer: it is the PermitUSB project backend, not a per-tenant URL.

Summary