Skip to main content
Use Netskope Forward to Proxy (F2P) to send selected AI traffic to a Forge proxy. Netskope selects the users and destinations; Forge receives the forwarded connection and the user evidence Netskope supplies.

​
Before you start

Have these items ready:
  • Administrator access to Netskope and an active Secure Web Gateway license.
  • Managed devices whose traffic is steered through Netskope.
  • The Forge proxy hostname, port, and public CA certificate supplied for your organization.
  • The users, directory groups, and source criteria to include in forwarding.
  • The AI destination domains to forward through Forge.
Define the protected population with user or group conditions and any required source criteria. A user condition can include multiple devices belonging to that user. Shared Netskope egress addresses do not identify individual devices.

​
Trust the Forge endpoint

  1. Open Settings → Manage → Certificates → Trusted CA.
  2. Select New Trusted Cert and upload the public CA PEM supplied by Forge.
  3. Validate and save the certificate.
This CA establishes Netskope’s trust in the proxy endpoint. It does not by itself establish client trust for decrypted traffic. Do not upload a private key or replace your organization’s signing CA.

​
Create the proxy profile

  1. Open Settings → Manage → Forward to Proxy Integration.
  2. Select Setup Proxy.
  3. Enter a profile name, such as Forge, and the Forge hostname and port.
  4. Enable X-Authenticated-User and set X-AU-Encode-Format to None.
  5. Save the profile.
Netskope includes the unmodified username in XAU on the CONNECT request. A reported username is provider evidence; it does not authenticate a Forge user on its own.

​
Create the destination list and category

  1. Open Policies → Profiles → URL Lists.
  2. Create Forge-AI-Domains with URL type Exact.
  3. Add the AI domains to forward. For ChatGPT and OpenAI API destinations, for example, use:
  4. Open Policies → Profiles → Custom Categories.
  5. Create Forge and include Forge-AI-Domains in its definition.
  6. Save and apply the category configuration.
Netskope’s wildcard syntax includes the root domain and its subdomains. Include file, asset, and application dependency domains required by the workflows you intend to forward. A forwarding list selects destinations; it does not select users.

​
Create the forwarding rule

  1. Open Policies → Real-time Protection and create a Web Access policy.
  2. Set Source to the users or directory groups to protect and any required source criteria.
  3. Set Destination → Category to Forge.
  4. Set Action → Forward to Proxy and select the Forge proxy profile.
  5. Review rule order, source scope, and existing bypasses with your network administrator before applying the rule.
Activating this rule changes the path of matching traffic. If the proxy is unavailable or rejects the connection, affected requests may fail. Verify the endpoint and certificate trust before applying the rule. Traffic that bypasses Netskope or skips RTP evaluation cannot be forwarded by this rule.

​
Delegate domain updates

To let Forge maintain the destination list, provide your tenant URL, list name or ID, and a service-account token authorized to read, update, and apply URL-list changes. Transfer the token through your approved secret-sharing channel. Create the service account under Settings → Administration → Administrators & Roles → Administrators. For RBAC v3, assign the corresponding URL-list management and apply permissions. Exact permission labels depend on your administration version; do not assume access can be restricted to one list. Netskope documents these REST API v2 operations: URL-list API v2 access may require Support to enable URL List enhancements. Confirm the request schema, apply permissions, and deployment scope in your tenant’s API documentation before automating writes. Do not deploy unrelated pending administrator changes. Use these operations to maintain the list without recreating the category or RTP rule. This procedure uses classic F2P and does not require Remote Proxy Beta.

​
Validate forwarding

  1. From a device in the protected population, request a listed destination.
  2. Confirm the matching policy and Forward to Proxy action in Netskope logs.
  3. Confirm that the corresponding connection reaches the assigned Forge endpoint.
  4. Verify that the CONNECT request includes XAU in the configured format.
  5. Request an unlisted destination and verify that it retains its existing path.
  6. Verify that excluded users or devices do not match the forwarding rule.

​
Disable forwarding

  1. Disable the dedicated RTP forwarding rule.
  2. Apply the configuration change.
  3. Verify that affected devices return to their expected network path.
Remove the proxy profile, category, and URL list only after no active rule references them. Stopping the proxy while the rule remains active can leave matching requests failing.

​
Netskope references