Coexistence: VPN, EDR, and filtering

The agent shares the device with a VPN client, an EDR agent, DNS filtering, and managed browsers. This page states how it interacts with each of them, from what the agent actually changes on a machine. It makes no claim of the form "tested with vendor X": the architectural interaction is described here, and the one-laptop step of the Endpoint pilot validates the combination on the firm's own stack with a checklist.

What the agent changes on a device

On Windows production installs, the agent adds one signed kernel component: a network driver, signed by Microsoft through its hardware certification program, that carries web connections through the agent's local checkpoint while the agent is healthy. Only destinations with positive AI evidence are opened; everything else passes through unread. The driver's authorization is a short lease: if the agent or its checkpoint stops being healthy, the lease lapses within seconds and traffic flows natively. Beyond that one component, the agent changes no routes and no network interfaces, does not alter DNS configuration, and adds no firewall rules. Trial and sandbox installs, and macOS today, capture through the proxy configuration above and load no driver; each device reports which capture mode it runs.

VPNs

The agent operates on the device, above the tunnel. It changes no routes, so whatever path the VPN establishes is the path traffic takes. For an AI destination, the request reaches the agent's local checkpoint (handed over by the proxy setting, or carried there by the Windows driver), and the agent's onward connection to the origin travels the same network path as any other process on the device, tunnel included.

• On macOS, a network service that already has an authenticated proxy configured is left untouched, because its credentials cannot be captured and restored losslessly. Traffic on such a service is not intercepted.
• On a fleet that forces all egress through a corporate proxy (Zscaler, Netskope, or a similar appliance), the agent is configured with that upstream at deployment through its managed UpstreamProxy key, and every outbound leg it makes chains through the corporate proxy. Without that configuration, the agent connects directly.

EDR and endpoint security

• The agent's service and companion run in user space on both platforms: a LaunchDaemon on macOS and a Windows service. The one kernel component is the Windows capture driver described above, signed by Microsoft, loading the way any signed Windows driver loads.
• The binaries are code signed: Developer ID signed and notarized on macOS, Authenticode signed on Windows, so an EDR that gates by publisher can pin trust to the signer.
• Security tooling is excluded from interception twice over. EDR and security-vendor hosts sit on the hard denylist the proxy consults before any AI check, so an endpoint agent's own traffic to its cloud is tunnelled untouched. The same categories are excluded in the CA certificate's name constraints.
• If any control blocks an origin connection the agent was relaying, the agent steps aside: the host drops to a direct tunnel for five minutes and a content-free event goes on the record. The blocking product's verdict is what the employee experiences.

DNS filtering

The agent does not change the device's DNS configuration. What a filter observes changes in one narrow way: for the AI hosts the agent relays, the lookup and the origin connection come from the agent process rather than the browser, on the same device and the same network. A destination the filter refuses stays refused: if the origin cannot be reached, the agent drops the host to a direct tunnel for five minutes, records a content-free event, and the native path receives the filter's answer.

DNS over HTTPS in managed browsers: on macOS the managed profile turns DoH off for Chrome, Edge, and Firefox, which keeps browser lookups on the resolver the firm's filtering watches. On Windows, capture does not depend on a browser policy and no DoH policy is set; a firm that locks browser DoH on Windows keeps doing so through its existing policy.

Browsers

On Windows production installs, the driver carries the connection to the agent's checkpoint regardless of which browser or HTTP stack the application uses. On proxy-mode installs (trials, sandboxes, and macOS today), capture rides the operating-system proxy setting, which Chromium-based browsers, Safari, and applications built on the platform HTTP stacks honour: the PAC routes only registry AI hosts to the local proxy, each with a direct fallback, and every other destination is listed direct and never touches the agent. Either way, for an intercepted AI host the browser sees a leaf certificate minted under the firm's CA; for everything else, the original certificate chain passes through untouched.

• On macOS, the managed profile locks Firefox to the system proxy configuration and imports enterprise roots. On Windows, the agent writes the Firefox enterprise-roots policy so Firefox trusts the certificate, and on production installs the driver does not depend on the browser's proxy mode at all.
• HTTP/3 runs over UDP, which a proxy does not carry. On Windows production installs, the driver declines UDP on port 443 only while the complete capture path is live, so browsers retry over connections the checkpoint reads; the moment the path is not live, nothing is declined and traffic flows natively. On macOS, the managed profile disables QUIC, encrypted client hello, and DoH for Chrome, Edge, and Firefox, so those browsers negotiate over TCP where the proxy operates.
• Certificate-pinned surfaces are passed through untouched, and desktop applications known to pin are bypassed by process. The full list of stated limits is in the security review.