This guide focuses on the technical network flows used to route generative AI traffic to SurePath AI. It covers SASE Forward-to-Proxy and Proxy PAC URL models, with and without upstream TLS interception. Configuration is intentionally generalized here; detailed, vendor-specific setup is linked for reference.

At a high level, both methods steer only GenAI domains to SurePath AI for governance. SASE deployments chain traffic with a Forward-to-Proxy action from the SASE vendor to the SurePath AI Proxy. Proxy PAC URL deployments configure endpoints to use a PAC file that sends matching traffic directly to the SurePath AI TLS proxy.

Choose SASE Forward-to-Proxy if your organization already routes web traffic through a SASE platform and you want centralized policy, posture controls, and consolidated logging across your security stack.

Choose Proxy PAC URL when you need a rapid deployment without SASE, when your primary target is browsers or ChromeOS, or to pilot/roll out to specific user groups using MDM or browser admin controls.

SurePath AI supports two primary types of integrations: SASE and Proxy PAC URL. SASE is the preferred method but for customer without a SASE solution or a compatible SASE solution, SurePath AI leverages MDMs to push out a customer-specific proxy PAC URL directly to the endpoints. Both methods result in only specific AI domains being forwarded to SurePath AI for analysis while non-AI traffic is sent via normal or direct routes. Below are descriptions and diagrams of different iterations of SASE and Proxy PAC URL traffic flows.

Endpoints retrieve the PAC file and direct only GenAI traffic to the SurePath AI TLS proxy while sending other traffic normally. Requests to public GenAI services are tunneled to SurePath AI Edge and inspected under the SurePath AI Root CA trusted by the endpoint.

A customer-managed firewall performs TLS inspection for outbound HTTP/S traffic, and the endpoint trusts the firewall’s CA. The PAC still directs GenAI traffic to the SurePath AI HTTP/S proxy. The SurePath AI Root CA must be installed on the firewall so that SurePath AI inspection of tunneled GenAI sessions succeeds end-to-end.

The SASE platform performs TLS intercept and then forwards GenAI traffic to the SurePath AI Proxy using a Forward-to-Proxy action based on the Public Services list. The SurePath AI Root CA must be installed on the SASE platform to allow downstream SurePath AI inspection.

The SASE forwards GenAI traffic to the SurePath AI Proxy without performing TLS intercept upstream. Endpoints must trust the SurePath AI Root CA to avoid browser warnings when SurePath AI performs TLS inspection.

Unlike intercepting external AI services, the SurePath AI private portal is always accessed directly. Traffic to and from the portal is always sent through an endpoint's normal traffic routing flows. Using the SurePath AI private portal does not require the SurePath AI root CA nor any special SASE configurations or proxy PAC URL to reach.

Updates to GenAI destinations are handled automatically via the Public Services Catalog and PAC file. SASE deployments may require periodic category list refreshes (per vendor guidance). For pilot deployments, use targeted user/device groups and monitor logs in both your SASE and SurePath AI.

In order for SurePath AI to associate AI traffic to specific users, SurePath AI must either prompt a user for credentials before allowing them to reach an AI service or an identifier must be passed to the SurePath AI edge service to associate the traffic to a user without authentication.

Most SASE vendors' Forward-to-proxy policies support adding the x-authenticated-user (XAU) header to requests forwarded to 3rd party proxy services like SurePath AI. If the XAU header is sent to SurePath AI and the tenant has the requisite SASE connector added and the request comes from a known IP address of that SASE vendor, then SurePath AI will trust the contents of the XAU header and automatically authenticate the request to that user without prompting for the user to authenticate.

Some vendors, like Cloudflare, don't yet support sending the XAU header and as such, XAU authentication is not available. In most cases, org-level identification is still possible, but user-level XAU authentication is not.

SurePath AI's proxy PAC URLs provide a primary TLS-based proxy address and HTTP fallback proxy address for systems or applications that don't support TLS proxies. Along with the added security, the TLS-based proxy also allows for the use of user-specific hostnames to help SurePath AI identify which tenant traffic should be assigned to. The Proxy connector has three authentication settings:

The above all assumes that the SurePath AI TLS proxy is being used. In the cases where the TLS proxy isn't supported, authentication always fallback to User authentication. Connector authentication is enabled via TLS proxy as a TLS connection contains a field called Server Name Indication (SNI). Essentially, this is a field that contains the DNS name of the host that the client is trying to reach. SurePath AI uses this field to associate traffic to a specific tenant when its available. In the case of HTTP proxy traffic, the SNI isn't available so it isn't possible to identify the org which mean SurePath AI must prompt users for authentication for all AI services.