Skip to main content
CID222 Docs

Fortinet FortiSASE

Add CID222 as an external ICAP inspection service in FortiSASE, or as an HTTP callout on a FortiGate too old for the ICAP profile.

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

FortiSASE is Fortinet's cloud-delivered gateway. It decrypts the session and can hand the decrypted request to an external inspection service, which is where CID222 fits. On an on-premises FortiGate the same integration is an ICAP profile; on releases before that profile matured it is an HTTP callout instead.

What do I need?

Licence
Any
Role
admin_user

Prerequisites

  • A FortiSASE tenant with the data-loss-prevention module, or a FortiGate on FortiOS 7.4 or later.
  • The CID222 ICAP listener published and reachable from the gateway on TCP 1344 — see ICAP and third-party gateways.
  • For a cloud-delivered tenant, the appliance reachable from Fortinet's egress addresses, and those addresses in the appliance's peer list.
  • Saving the appliance-wide inspection policy requires the superadmin account.

Warning

Written from Fortinet's own documentation and the CID222 inspection contract. Not verified against a live FortiSASE tenant. The on-premises path through FortiProxy 7.4.13 is lab-verified — see FortiProxy and FortiGate — and where the two disagree, trust that page.

Configure the gateway

Under Security → DLP → External ICAP, add a server with the appliance's address, port 1344, request modification enabled, and a failure action that matches the posture you set on the appliance.

Then bind it in a data-loss-prevention profile matching the FortiGuard Generative AI URL category, and apply that profile to the policies carrying user web traffic.

FortiGuard maintains the category centrally. New products appear in it some weeks after they launch, so keep a custom category alongside it and match on both.

Verify

  1. From a workstation behind the gateway, send a prompt containing a test identifier. The model receives it masked, or the request is refused.
  2. Select Detection & Filtering → All Detections and filter to browser traffic. The attempt appears as MESSAGE_MASKED or MESSAGE_BLOCKED with the hostname and source address.
  3. On Browser Inspection, the gateway appears in the connected-sources table.

If it fails

  • Nothing reaches the appliance → check the port from the gateway's own network first, then the appliance's peer list; a cloud tenant dials from public addresses that the private-range default refuses.
  • The user sees Fortinet's own block page instead of the reason CID222 returned → the replacement message group is substituting its template. Set it to pass the response through if the reasons must reach the user.
  • Uploads are not inspected while prompts are → the upload hosts are outside the category.
  • Every caller arrives with the same address → Every ICAP caller arrives as the same docker bridge address.

Next steps

Last updated on

On this page