Palo Alto Networks

Forge supports two Palo Alto deployment types. Choose the one that matches how your organization routes user traffic: For traffic that reaches Forge, both deployments use the same supported Forge inspection, policy, and activity pipeline. Forge routes native application, developer API, and MCP traffic to the matching enforcement path. The deployment type changes the network setup and available identity context, not the Forge policy model. The deployment type is fixed after a connection is created. Create a separate Palo Alto connection to use the other deployment type.

​

Standalone PAN-OS with GlobalProtect

The standalone integration provides two complementary enforcement paths: Gateway routing sends supported model, browser AI, developer API, and MCP traffic through the matching Forge inspection path. Native web, desktop, and CLI traffic keeps its existing provider login. Explicit API-key traffic uses the LLM Gateway, and registered MCP traffic uses the MCP Gateway. Forge applies the same identity, access, content, and tool policies across those paths. Native enforcement covers the broader Forge AI catalog with PAN-OS security controls. It does not redirect or decrypt matching traffic through Forge. You select the users and devices protected by Gateway routing. Forge keeps the destination and routing set current, then automatically sends matching traffic to the right Forge Gateway. Users do not need to configure individual AI tools or applications.

​

Setup at a glance

Connect PAN-OS, prepare the private path, match GlobalProtect sessions to Forge devices, establish certificate trust, then review and activate. Forge guides each step and shows what remains before routing can begin.

​

Before you start

Have these items ready:

• A PAN-OS management URL that Forge can reach over HTTPS.
• A dedicated PAN-OS XML API key with Configuration, Operational Requests, Log, and Commit access.
• The administrator name that issued the API key.
• An existing GlobalProtect gateway with tunnel mode and an IPv4 client pool.
• The public IPv4 address that terminates the firewall side of the IPsec tunnel.
• The users and their assigned devices in Forge.
• An enterprise CA that can sign the Forge certificate request.

Forge discovers and uses the existing GlobalProtect configuration. It does not create or change the GlobalProtect portal, gateway, client settings, user access, or address pool.

​

Connect PAN-OS

Open Settings > Integrations > Palo Alto Networks.

1. Enter a Firewall name.
2. Enter the PAN-OS management URL.
3. Paste the API key.
4. Allow Forge to manage its PAN-OS network and forwarding objects.
5. Enter the PAN-OS administrator name that issued the key.
6. Select Connect and discover.

Forge reads the firewall model, PAN-OS version, GlobalProtect network, and routing setup before making changes.

​

API key

Create the key through the PAN-OS XML API. Paste only the value inside the returned <key> element. Do not enter the administrator username or password in Forge. Use a dedicated PAN-OS administrator with Configuration, Operational Requests, Log, and Commit access. See Palo Alto Networks’ API authentication documentation.

​

Management certificate

When the management URL uses a private or self-signed certificate, provide the SHA-256 fingerprint of the certificate used by the management HTTPS service. Leave the fingerprint empty when the management URL uses a publicly trusted certificate.

​

Prepare the private path

Complete each section shown on the Palo Alto Networks setup page.

​

Select the GlobalProtect network

If Forge discovers more than one supported GlobalProtect client network, choose the network whose devices should be eligible for routing. The GlobalProtect gateway must use tunnel mode, have an IPv4 client pool, and connect its tunnel interface to one zone and one virtual router.

​

Prepare the secure path

1. Enter the firewall’s public VPN address.
2. Select Prepare secure path.
3. Review the PAN-OS changes shown by Forge.
4. Confirm the changes.

Forge prepares both sides of a private IKEv2/IPsec tunnel. It creates or reuses only Forge-owned tunnel and routing objects. If an existing PAN-OS object conflicts with the requested configuration, Forge stops and reports the conflict instead of modifying that object. Preparing the tunnel does not redirect user traffic. Forge first commits and checks the tunnel configuration.

​

Choose people

Configure how GlobalProtect usernames map to people in your directory, then select the people or directory groups Forge should protect.

1. Choose the username format used by GlobalProtect, such as full email, email username, or domain and username.
2. Review the directory matches and add an exact override only when a username cannot be mapped unambiguously.
3. Select the people or directory groups to protect.
4. Select Save and check.

A selected person remains protected whenever they connect through GlobalProtect; they do not need to be online during setup. Current GlobalProtect sessions are used as short-lived address and device evidence, not as durable setup state. When a session ends, its earlier VPN address is no longer eligible for forwarding.

​

Automatic Gateway routing

Forge publishes the current supported routes for:

• Supported native provider and web traffic handled by Forge native inspection while preserving the provider login.
• Explicit API-key traffic handled by the LLM Gateway.
• Registered MCP traffic handled by the MCP Gateway.

PAN-OS forwards those destinations through the private tunnel only for current, selected GlobalProtect devices. Forge then sends each supported request to the appropriate Gateway. Route and certificate updates are applied when the supported routing set changes. Unsupported destinations and unrelated traffic keep their existing network path. Clients configured with an explicit Forge LLM Gateway or MCP Gateway URL already connect directly to Forge. Those explicit Gateway URLs do not need PAN-OS steering.

​

Establish certificate trust

Sign the Forge subordinate certificate with your enterprise CA so managed devices can trust the Forge Gateway.

1. Select Start certificate setup.
2. Download the signing package.
3. Sign the included CSR with your enterprise CA according to the requirements in the package.
4. Return one PEM file containing the signed Forge subordinate certificate first, followed by any non-root intermediate certificates.
5. Approve the certificate for Gateway inspection and select Return signed certificate.

The signing package does not contain the Forge private key or another secret. Forge protects its private key and does not export it. Do not upload an enterprise root certificate or private key. Managed devices must already trust the enterprise CA through the organization’s normal device management process.

​

Review and activate

Forge activates forwarding only after the private tunnel, protected people, automatic Gateway routes, and certificate trust are ready. When active, PAN-OS forwards traffic only when:

• It comes from a current GlobalProtect session for a protected person.
• Its destination is included in the current Forge routing set.

Other users and unrelated traffic retain their existing routes.

​

Native access policies

Forge can also compile Access policies into PAN-OS security controls: If applications are omitted, Forge can infer a narrow App-ID set from supported provider or domain conditions. Forge does not widen an untranslatable policy into an unrestricted application match. Native rules execute in PAN-OS and do not require Gateway routing. Use them for broad destination access control when prompt, response, or tool-level policy evaluation is not required.

​

Traffic evidence

Forge can collect PAN-OS traffic evidence after network enforcement: PAN-OS traffic logs prove network activity and enforcement. They do not prove prompt, response, or tool content. Content visibility requires a verified route through the matching Forge native, LLM Gateway, or MCP Gateway runtime.

​

Standalone troubleshooting

​

Forge cannot connect

• Confirm the management URL is reachable over HTTPS.
• Confirm the API key is current and has the required access.
• Confirm the administrator name matches the API key owner.
• If requested, confirm the management certificate fingerprint.

​

No GlobalProtect network appears

• Confirm tunnel mode is enabled on the GlobalProtect gateway.
• Confirm the gateway has a tunnel interface and IPv4 client pool.
• Confirm the tunnel interface belongs to one zone and one virtual router.
• Return to Forge and select Check PAN-OS again.

​

No live session appears

• Connect the device through GlobalProtect.
• Confirm its username matches a protected person in Forge.
• Check current identity status again.

A live session is required for that person’s traffic to be forwarded, but it is not required to finish selecting people during setup.

​

Forwarding is not active

Confirm that the private tunnel, protected people, automatic Gateway routes, and certificate trust all show as ready. Configure forwarding shows the remaining issue.

​

Panorama-managed Prisma Access Explicit Proxy

Use this path when Panorama manages an existing Prisma Access Explicit Proxy. Prisma decrypts the selected traffic and chains it to Forge over TLS. For traffic that reaches Forge, the same supported Forge policies and activity processing apply. This path attributes activity to the person and does not claim device identity.

​

Setup at a glance

Connect Panorama, configure the Explicit Proxy chain, match Prisma usernames to Forge people, then verify forwarding and activity for the protected group.

​

Before you start

Have these items ready:

• A Prisma Access Mobile User license, Prisma Access 5.2.2, and PAN-OS dataplane 11.2.6, as required by Palo Alto Networks for proxy chaining.
• An existing Mobile Users—Explicit Proxy deployment.
• The Panorama management address and a dedicated XML API key with read access to system, Cloud Services, and security rulebase configuration.
• The exact Explicit Proxy device group and, for multi-tenant Panorama, the exact Prisma tenant name.
• The IPv4 egress CIDRs Prisma uses for upstream proxy connections.
• Directory users synchronized into Forge and the people or groups to protect.
• The Forge Prisma ingress hostname.

For agent-based tunnel-and-proxy mode, Palo Alto Networks requires GlobalProtect 6.2 on Windows or macOS and content release 8700-7994 or later.

​

1. Connect Panorama in Forge

Open Settings > Integrations > Palo Alto Networks.

1. Select Panorama-managed Prisma Access.
2. Select the Panorama tenancy mode and enter the tenant name when required.
3. Enter the exact Explicit Proxy device group.
4. Enter the Trusted Prisma source CIDRs, one IPv4 CIDR per line.
5. Enter the Panorama name, HTTPS management address, and XML API key.
6. Add the management certificate fingerprint when Panorama uses a private or self-signed certificate.
7. Select Connect Panorama.

A successful connection proves that Forge can read Panorama. It does not mean that Prisma traffic is already being forwarded.

​

2. Configure Prisma in Panorama

For the protected scope:

1. Enable Explicit Proxy authentication.
2. Select only the approved AI destinations in the forwarding profile and decryption policy.
3. Add an App-ID quic deny and a UDP/443 deny above the applicable allow rules so traffic cannot bypass the proxy over HTTP/3.
4. Create an upstream proxy profile for the Forge hostname on port 443 with TLS enabled.
5. Share X-Authenticated-User and X-Forwarded-For at the HTTP layer.
6. Add an enabled upstream proxy rule for only the protected users and approved destinations with Failclose as the fallback action.
7. Commit in Panorama and push to the Explicit Proxy device group.

Do not include Prisma, GlobalProtect, identity-provider, or authentication service domains in the forwarding scope.

​

3. Choose people in Forge

1. Open People and groups for the Palo Alto connection.
2. Choose the username format Prisma sends in X-Authenticated-User.
3. Review the directory matches and add an exact override only when required.
4. Select the people or groups to protect.
5. Select Save and check.

Each Prisma request must come from a configured trusted CIDR and resolve to one active, protected Forge user.

​

4. Verify and roll back

1. Send a protected person’s approved AI traffic through Prisma.
2. Confirm the activity appears in Forge for the correct person.
3. Confirm an unselected person and unrelated destinations keep their existing path.
4. Confirm the selected traffic cannot reach the provider directly over QUIC.
5. Repeat with another approved destination.

To roll back, disable the Forge upstream proxy rule in Panorama and push the change to the Explicit Proxy device group. Confirm the protected traffic returns to its previous Prisma route before re-enabling the rule. Do not change the fallback action to Failopen for rollback. Keep Failclose and disable the reviewed rule explicitly.

​

Prisma troubleshooting

• Panorama connects but traffic is not forwarded: confirm the exact tenant, device group, source CIDRs, and API read permissions, then select Save and check again.
• Forge denies the request: confirm the source CIDR, one X-Authenticated-User value, directory match, protected-user selection, and decrypted destination.
• Traffic works but is absent from Forge: confirm the App-ID quic and UDP/443 denies are enabled and above the allow rules.
• Prisma cannot reach Forge: use the Forge hostname rather than its IP and confirm port 443, TLS, IPv4 resolution, and public certificate trust.

​

Related pages