Connect Netskope to the CID222 HTTP inspection endpoint, with the exact request and response shapes the gateway must send and enforce.

Netskope calls an external inspection service over plain HTTPS rather than the ICAP wire protocol, so the integration is a webhook rather than a service entry: one URL, one credential, and a policy rule that decides which traffic is sent. This page carries the exact request and response shapes, because they are the part a gateway configuration can get wrong silently.

What do I need?

Licence: Any
Role: admin_user

Prerequisites

A Netskope NewEdge or Next Gen Secure Web Gateway tenant with the cloud data-loss-prevention module.
A way for Netskope's cloud to reach the appliance: a public name with a certificate, a Netskope private connector, or a tunnel.
A gateway API key issued on the appliance — a keyless call through the public edge is refused.
Saving the appliance-wide inspection policy requires the superadmin account.

Warning

Written from Netskope's own documentation and the CID222 inspection contract. Not verified against a live Netskope tenant. The request and response shapes below are verified — they are read from the gateway's own request and response definitions.

The contract

Netskope sends one request per inspected message to POST /inspect/v1/<hostname>, where the last path segment is the destination hostname of the intercepted request:

{
  "direction": "request",
  "payload": "…the decrypted HTTP body…",
  "payloadEncoding": "text",
  "contentType": "application/json",
  "requestPath": "/backend-api/conversation",
  "sourceIp": "10.0.5.42",
  "authenticatedUser": "jdoe@example.corp",
  "correlationId": "…",
  "metadata": { "ns_event_id": "…" }
}

Only direction and payload are required. Set payloadEncoding to base64 when the body is binary — an image or a file upload — and leave it out or set it to text for a UTF-8 body. metadata is free-form; CID222 preserves an external_trace_id in it verbatim so a verdict can be correlated with the gateway's own record.

The answer is one object:

{
  "verdict": "REDACT",
  "redactedPayload": "…the body to forward instead…",
  "redactedPayloadEncoding": "text",
  "reasons": ["PII: national_id"],
  "latencyMs": 142,
  "detectionCount": 1,
  "correlationId": "…"
}

Netskope must enforce all three verdicts: forward the original body unchanged, forward redactedPayload in place of the original, or refuse the request and serve its own block page. A gateway that forwards the original body on a redact verdict has inspected the traffic and leaked it anyway.

Danger

A call to the inspection endpoint that carries no gateway API key is refused when it arrives through the appliance's public edge. Issue a key for this integration and set it as a bearer token; do not rely on network position.

Configure the tenant

Add CID222 as an external inspection service

In the tenant's web data-loss-prevention settings, add a service posting to https://<appliance-fqdn>/inspect/v1/{hostname} with a JSON body, the gateway API key as a bearer token, and connect and read timeouts sized for your network.

The placeholder is substituted by Netskope at runtime with the destination hostname of the intercepted request.

Bind it to the generative-AI category

Add a real-time protection rule matching Netskope's centrally maintained generative-AI category with the action of external inspection through that service.

The category is maintained centrally and covers a large number of products, so you can bind to the whole category rather than maintaining a hostname list. Confirm it includes the hosts that carry uploaded file bytes.

Agree the failure posture

Set the tenant's action on failure to match the appliance's Fail closed (BLOCK) on timeout on Detection & Filtering → Browser Inspection.

Both ends now behave the same way when a verdict does not arrive in time.

Note

Allowed ICAP peer IPs / CIDRs does not gate this path — it applies to the ICAP listener on port 1344 only. Admission here is the gateway API key, and optionally a client certificate.

Verify

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

If it fails

The appliance answers with an authorisation failure → the request carries no gateway API key, or a client subject name is configured on the policy and none is being forwarded.
The appliance answers with a validation error → the body is missing direction or payload, or binary content was sent without payloadEncoding set to base64.
Prompts are masked in the event log but reach the model intact → the tenant is not forwarding redactedPayload on a redact verdict.
Uploads are not inspected → the category does not cover the host that carries the file bytes.

Next steps

ICAP and third-party gateways — the shared contract and the attribution chain.
Interception topologies — what this deployment cannot see.

Netskope NewEdge