Add CID222 as an external data-loss-prevention server on Skyhigh Secure Web Gateway or on-premises McAfee Web Gateway.

Skyhigh Secure Web Gateway — the product formerly sold as McAfee Web Gateway, briefly as Trellix — calls external scanners over the same protocol CID222 serves. This procedure adds the server, binds it to the gateway's own generative-AI category, and admits the gateway's addresses.

What do I need?

Licence: Any
Role: admin_user

Prerequisites

Skyhigh Secure Web Gateway (cloud) or McAfee Web Gateway 11.x on premises. The cloud access security broker product does not do inline inspection of web traffic and cannot be used here.
Administrative access to the Skyhigh console, or to the on-premises web console.
The CID222 ICAP listener published and reachable from the gateway on TCP 1344 — see ICAP and third-party gateways.
For the cloud product, Skyhigh's published egress ranges, and those ranges in the appliance's peer list.

Warning

Written from Skyhigh's own documentation and the CID222 inspection contract. Not verified against a live Skyhigh deployment. Console paths are a guide to the right screen, not a transcript, and the on-premises console arranges these settings differently from the cloud one.

Configure the gateway

Add CID222 as an external server

Under Policy → Web → External DLP Server, add a server named cid222 with the URL icap://<appliance-ip>:1344/inspect, request modification as its method, and forwarding of the authenticated user and client address enabled.

On an on-premises gateway the same fields live under the external-lists section of the policy settings.

Bind it to the generative-AI category

Under Policy → Web → Web Filter, add a rule matching the gateway's Generative AI category with the action of external inspection through cid222, and deploy.

The rule reaches the enforcement nodes within about a minute. Verify the category actually contains the hostnames you care about, including the hosts that carry uploaded file bytes, and extend it with a custom category where it does not.

Admit the gateway's addresses

Select Detection & Filtering → Browser Inspection, and add Skyhigh's published egress ranges to Allowed ICAP peer IPs / CIDRs. Select Save policy.

The panel reports Inspection policy updated. The list replaces the private-range default, so add every on-premises peer and every test host in the same edit.

Verify

From a workstation behind the gateway, send a prompt containing a test identifier. The model receives it masked, or the browser shows a block page.
Select Detection & Filtering → All Detections and filter to browser traffic. The attempt appears as MESSAGE_MASKED or MESSAGE_BLOCKED.
On Browser Inspection, the gateway appears in the connected-sources table.

If it fails

Nothing reaches the appliance and the log records a refused connection → the peer list does not cover the range this node dialled from. Cloud egress ranges change; re-read the vendor's list.
The category matches nothing → the deployment is the cloud access security broker rather than the secure web gateway, and does not inspect web traffic inline.
Every caller arrives with the same address → Every ICAP caller arrives as the same docker bridge address.

Next steps

ICAP and third-party gateways — the contract and the admission rules.
Interception topologies — what this deployment cannot see.

Skyhigh Security