Skip to main content
CID222 Docs

Palo Alto Prisma Access

Connect Prisma Access to the CID222 HTTP inspection endpoint and bind it to a generative-AI policy.

  • Version: 0.4
  • Feature: icap
  • Role: admin_user
  • Type: task

Prisma Access is Palo Alto's cloud-delivered gateway. Like Netskope it calls an external inspection service over HTTPS rather than the ICAP wire protocol, so CID222 is configured as an external service and bound to a policy.

What do I need?

Licence
Any
Role
admin_user

Prerequisites

  • A Prisma Access tenant with the cloud data-loss-prevention capability, or PAN-OS 11.x with the same module on premises.
  • A way for the cloud to reach the appliance: a public name with a certificate, or a connector inside your network.
  • A gateway API key issued on the appliance — a keyless call through the public edge is refused.
  • Palo Alto's published egress ranges, if you also expose the ICAP listener to this tenant.

Warning

Written from Palo Alto's own documentation and the CID222 inspection contract. Not verified against a live Prisma Access tenant. The console has been reorganised at least once — newer deployments use the unified manager, where these settings sit under a different path — so treat the menu names as a guide to the right screen.

Configure the tenant

Add CID222 as an external service

In the tenant's service setup, add an external inspection service posting to https://<appliance-fqdn>/inspect/v1/{hostname} with the gateway API key as a bearer token and a timeout sized for a cloud round trip.

The request and response shapes are the same as on the Netskope NewEdge page.

Bind it to a generative-AI policy

Add an external-inspection policy matching the generative-AI URL category, and match on the application signature as well as the category.

Matching both survives a provider moving an endpoint: the signature keeps matching when the hostname changes.

Confirm the identity Prisma forwards

Where the tenant is integrated with your directory, the resolved identity is forwarded with each request.

Events then name a person. CID222 normalises the domain-qualified and user-principal forms to one identity, so the same person does not appear twice.

Warning

A managed browser is not the whole estate. Where users also have an unmanaged browser installed, traffic from it bypasses a policy that only covers the managed one. Cover the network path as well, or state the gap.

Verify

  1. From a workstation whose traffic the tenant forwards, send a prompt containing a test identifier. The model receives it masked, or the tenant's block page appears.
  2. Select Detection & Filtering → All Detections and filter to browser traffic. The attempt appears as MESSAGE_MASKED or MESSAGE_BLOCKED, carrying the directory identity.
  3. On Browser Inspection, the tenant appears in the connected-sources table.

If it fails

  • The appliance answers with an authorisation failure → no gateway API key on the call, or a client subject name is configured on the policy and none is forwarded.
  • The policy matches nothing → the category is not populated for this tenant, or the settings were applied in the legacy console while the tenant reads the unified one.
  • Traffic from some users is never inspected → they are reaching providers through a browser or a network path the tenant does not cover.

Next steps

Last updated on

On this page