Network allowlist

PermitUSB has two independent network paths. They have different allowlist requirements, and conflating them is the most common cause of "the agent stopped reporting overnight" tickets.

The endpoint agent

The Windows agent runs as a LocalSystem service and talks to exactly one destination:

*.permitusb.com        (HTTPS / 443)

That is the entire agent surface. The agent never contacts Supabase, Vercel, or any third-party host directly - everything goes through the PermitUSB API on the permitusb.com domain. If you only deploy the agent and never open the dashboard from inside the restricted network, this one entry is all you need.

Identity-aware proxies / secure web gateways

If your egress runs through an identity-aware proxy or SWG (Zscaler, Cisco Umbrella SWG, Netskope, Forcepoint, FortiGate with FSSO, Palo Alto with proxy auth, etc.), you must add a destination-based authentication bypass for *.permitusb.com.

Why this matters: these proxies map outbound traffic to a logged-in user. The agent runs as a machine service with no interactive user. While someone is signed in, the proxy's IP-to-user mapping covers the machine and the agent works. When the user signs out (machine still powered on at the lock / login screen), that mapping expires - the agent's requests are no longer attributable to a user and the proxy returns 403 Forbidden. The agent keeps using its cached access token until it expires, then goes quiet until someone signs back in. Symptom: a subset of machines silently stop reporting after hours and recover the next morning.

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

FortiGate example

Create an FQDN address object for *.permitusb.com, then a firewall policy to that destination on HTTPS with no source user / FSSO group requirement and Captive Portal disabled, ordered above your authentication-required outbound policy (FortiGate matches top-down):

config firewall address
    edit "permitusb-fqdn"
        set type fqdn
        set fqdn "*.permitusb.com"
    next
end
config firewall policy
    edit 0
        set name "PermitUSB-agent-noauth"
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "LAN_subnet"
        set dstaddr "permitusb-fqdn"
        set action accept
        set schedule "always"
        set service "HTTPS" "DNS"
        set ssl-ssh-profile "certificate-inspection"
        set nat enable
    next
end

Then move the new policy above the FSSO policy: config firewall policy → move <newID> before <fsso-policy-ID>. Wildcard FQDN in policy needs FortiOS 6.4+; on older builds use the specific host agent.permitusb.com plus your API host. Use certificate-inspection(SNI-only) rather than deep inspection on this policy so TLS interception doesn't interfere with the agent.

The dashboard (admin browser)

IT 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:

*.permitusb.com                       (HTTPS / 443)
eywrcbladgkyplwetfuk.supabase.co      (HTTPS / 443, WebSocket)

This is a browser-and-human path, not the agent path. A blocked Supabase host here fails loudly and immediately (the admin can't sign in) rather than causing the silent agent drift above, so it's lower risk - but allowlisting it avoids a confusing first-login experience. The Supabase host is the same for every customer; it is the PermitUSB project's backend, not a per-tenant URL.

Summary