Skip to main content
The Zscaler Internet Access integration uses synchronous proxy forwarding to send selected AI traffic through Forge. Forge applies Access and content policy and produces Traffic, Session, and Shadow AI activity from the inline path. ZIA steering is not available for customer activation until its proxy endpoint, certificate, forwarding, traffic, and rollback behavior complete live qualification.

​
Availability and validation

Do not deploy forwarding changes from this overview. Customer activation needs a qualified allow/block/recovery test, certificate trust, identity attribution, and verified rollback. Provider connectivity alone does not establish inline coverage. Credential and permission steps will accompany the supported setup.

​
Intended traffic path

ZIA decrypts the selected connections so it can attach its authenticated user identity. Forge accepts identity only from the authenticated customer attachment and strips provider identity headers before forwarding upstream. Forge manages the selected destination set, forwarding configuration, readback, drift repair, rollback, and cleanup wherever the ZIA API supports those operations. A customer performs only the setup steps ZIA does not expose through an API, including creation or authorization of the Proxy Gateway when required. Forge does not use OneAPI polling or Web NSS imports as traffic evidence, and it does not compile Forge Access policies into ZIA-native URL or firewall rules. Unrelated traffic remains on the customer’s existing ZIA path. Detailed setup instructions will be published after live qualification is complete.