Interception topologies

Traffic reaches a commercial model three different ways — an application calling an API, a browser talking to a provider's web application, and a desktop tool speaking its own protocol — and each one terminates somewhere different. CID222 offers six interception points. Which one you deploy decides what is visible; nothing downstream of that choice can recover traffic the interception point never saw.

The problem

TLS is doing its job. When an employee opens a provider's website in a browser, the browser negotiates an encrypted session directly with the provider, and any device on the path sees ciphertext. There are exactly two ways to read that content: be the endpoint the client deliberately talks to, or decrypt the session with a certificate authority the client already trusts. Everything below is one of those two.

The distinction that decides most deployments is between a reverse proxy — traffic comes to a name you own, and you are the legitimate destination — and a forward proxy — traffic passes through you on its way to a name someone else owns. Putting CID222 in front of your own application is the first. Seeing a browser go to a provider's website is the second, and it needs either your own decrypting proxy, a gateway that already decrypts, or software on the device.

How CID222 does it

Whichever point carries the traffic, the same detection pipeline and the same policy decide the outcome, and every verdict lands in one All Detections feed.

Screenshot pendingDiagram: application, browser and desktop traffic reaching one detection pipeline through the API gateway, the inline proxy, a third-party gateway over ICAP, the endpoint agent and the browser extension/assets/screenshots/deploy-topologies@0.4.png

API gateway

Applications send requests to CID222 instead of to the provider. CID222 holds the provider credential, runs the pipeline on the request, forwards it, runs the pipeline again on the response, and returns the result.

This is the only path that sees a complete request and response pair and attributes it to a named account without guessing. It sees nothing a developer did not deliberately route at it.

Inline proxy

cid-inline-proxy is an opt-in forward proxy built on mitmproxy, started with the inline-proxy compose profile. It decrypts the session with a certificate authority generated on the appliance, submits the decrypted body to the gateway's inspection endpoint, and enforces the verdict — forwarding as-is, forwarding a redacted body, or answering the browser with a 403 page.

It listens on two ports: 8443 for browsers configured with an explicit proxy, and 8084 for a firewall that redirects traffic transparently. It runs on the host network namespace so that client addresses arrive as themselves.

Use it where the customer has no secure web gateway of their own. It puts CID222 in the data path, so an outage affects egress for the hostnames routed at it.

Third-party gateway over ICAP

Where the customer already runs a secure web gateway, that product is already the TLS endpoint and its authority is already on every managed device. CID222 becomes a scanner it calls: an Internet Content Adaptation Protocol (ICAP) listener on TCP 1344, or an HTTP inspection endpoint for cloud-delivered gateways that prefer one.

This is the cleanest enterprise fit. One certificate authority instead of two, no extra hop, and CID222 is not a single point of egress failure — the gateway's own on-failure setting decides what happens when the scanner is unavailable. It is also the only path validated end to end against a real gateway product; see ICAP and third-party gateways.

Endpoint agent

The agent enforces at the operating system on the workstation itself, which covers desktop tools that do not honour a system proxy and devices that leave the corporate network. It carries the same inspection logic as the inline proxy and generates its own per-device certificate authority rather than using the appliance's.

Browser extension

The extension is the one path that does not decrypt anything: it reads what the user typed in the page before the browser encrypts it. There is no certificate authority to distribute and no interception to break.

It also does not block by itself. It proves it is running by signing a heartbeat with a non-extractable device key; CID222 publishes the addresses of healthy devices as an external dynamic list, and the customer's existing firewall permits provider traffic only from that list. The firewall is the control; the extension is the evidence. A user who removes the extension loses access rather than gaining an uninspected path.

Claude Code plugin

The plugin routes a coding assistant's traffic through the gateway. Because it relays real API traffic rather than a web frontend, it is the only proxied path that records the provider's own token counts as CLAUDE_CODE_USAGE rather than an estimate.

Which one to choose

One hostname, one inspection point

A given hostname must be inspected at exactly one place. Either the gateway sends it to CID222, or CID222's inline proxy inspects it — never both.

Text survives double inspection: masking is idempotent, so the second pass re-masks or finds nothing. Images do not. The first pass re-encodes the image while redacting it, and the second pass cannot cleanly re-process that re-encoded blob, so it refuses the upload. Measured on the validation rig: a ChatGPT image upload redacted by the inline proxy, then inspected again over ICAP by the gateway in front of it, came back to the browser as a 403.

When CID222's inline proxy sits in front of an existing gateway, that gateway must be reduced to plain forwarding for the provider hostnames — no deep inspection and no inspection profile on the policy that carries them.

Limits and known gaps

• A device you do not manage cannot be intercepted. Interception depends on a certificate authority in the client's trust store. On a personal device there is none, and there is no engineering answer to that — only device management or a decision to deny the traffic.
• Applications that pin certificates cannot be intercepted. Mobile provider apps commonly pin, and refuse a session presented by any proxy. Control them at the mobile-device-management layer, or record the gap.
• On-device models produce no network traffic at all. A model running inside the browser or the operating system makes no request for any network control to see.
• HTTP/3 is not intercepted. The interception engine does not decrypt QUIC. Block UDP 443 to the provider hostnames so clients fall back to TCP, or those sessions bypass inspection.
• Chunked and resumable uploads are refused, not inspected. A fragment of a multi-request upload cannot be inspected on its own, so all three capture paths refuse it by default. The user sees a failed upload, not a redaction.
• Very large bodies are forwarded without inspection on the inline-proxy path. The proxy skips text bodies over 512 KB and binary bodies over 25 MB rather than blocking them. This is a silent pass-through, unlike the refusal above.
• The ICAP listener cannot authenticate its peer, and in a same-host virtual-machine laboratory it cannot even see who is calling. See ICAP and third-party gateways and the runbook Every ICAP caller arrives as the same docker bridge address.
• Only one gateway product is lab-verified. FortiProxy 7.4.13 has been validated end to end with an acceptance test plan. The other vendor pages are written from vendor documentation and say so.

Related tasks

• Deploy the inline proxy — make CID222 the gateway for browser traffic.
• ICAP and third-party gateways — connect an existing secure web gateway.
• Network prerequisites — the ports each of these topologies needs open, and in which direction.