Deployment modes
The six ways CID222 can be put in the traffic path, compared on what each one sees, what it needs on the client, and which package includes it.
- Version: 0.4
- Role: admin_user, viewer
CID222 offers six places to intercept traffic. The choice decides what is visible; nothing later in the pipeline can recover traffic the interception point never saw. This page compares them so you can pick before you read the deployment procedure.
The problem
The same organisation reaches models three ways at once — applications calling an API, people typing into a provider's website, and desktop tools speaking their own protocols. Each path ends somewhere different, and each has a different answer to the only question that matters for interception: who is the endpoint of the TLS session, and whose certificate authority does the client trust?
Deploying one mode and assuming coverage is the common mistake. An API gateway that governs every internal application still sees nothing when an employee opens a provider's website in Chrome.
How CID222 does it
| Mode | What it sees | What the client needs | Package | Deployment guide |
|---|---|---|---|---|
| API gateway | Full request and response for applications that address CID222 instead of the provider | A base-URL change and a gateway key. No certificate work | All packages | Getting started |
| Inline proxy (CID222 is the gateway) | Browser traffic to the provider hostnames in the inspection policy, decrypted by CID222 | CID222's proxy certificate authority in the trust store, plus a proxy setting or a firewall redirect | All packages | Inline proxy |
| Third-party secure web gateway over ICAP | Whatever the customer's own gateway already decrypts and sends for inspection | Nothing new — the gateway's authority is already installed | All packages | ICAP and third-party gateways |
| Endpoint agent | Traffic from the workstation, including desktop tools that ignore a system proxy, on or off the corporate network | The agent installed, with the per-device authority it generates | All packages | Endpoint agent |
| Browser extension | What the user types and uploads in the managed browser, read before encryption | The extension, deployed by managed browser policy | All packages | Browser extension |
| Claude Code plugin | Coding-assistant prompts, tool commands and tool output, plus repository and session audits | The plugin and a managed setting that points the assistant at the gateway | All packages; the code-safety tool gate needs Enterprise | Claude Code plugin |
Whichever mode carries the traffic, the same detection pipeline and the same policy decide the outcome, and every verdict lands in the same detections feed.
Where the licence actually bites
The package column above describes the administration surface, which is what the licence gates. The data paths are deliberately left ungated so that a late renewal darkens a console rather than stopping traffic: the inspection endpoint the proxies and gateways call, and the endpoint agents' own enrolment, policy and heartbeat API, keep working while a licence dispute is resolved. What a lapsed licence does stop is the product itself, through the global expiry block. See packages and licence tiers.
Choosing between them
- You control the applications. Use the API gateway. It is the only mode that sees a complete request and response pair and attributes it to a named account without inference, and it needs no certificate distribution.
- The customer already runs a secure web gateway. Use ICAP. Their product is already the TLS endpoint and their authority is already on every managed device, so there is one certificate authority instead of two and CID222 is not a single point of egress failure. This is also the mode with the better file-upload behaviour, because a gateway reassembles a multipart body before it calls the scanner.
- The customer has no secure web gateway. Use the inline proxy. CID222 becomes the forward proxy, which means it is in the data path for the hostnames routed at it.
- Desktop tools, or laptops that leave the network. Use the endpoint agent. It enforces at the operating system rather than at a network hop.
- You want evidence rather than interception. Use the browser extension. It decrypts nothing; it proves it is running by signing a heartbeat with a non-extractable device key, and CID222 publishes healthy devices as a list your existing firewall permits AI traffic from. The firewall is the control; the extension is the evidence.
- Coding assistants. Use the Claude Code plugin alongside whichever of the above carries the rest of the traffic.
These are not exclusive. Most deployments combine an API gateway for internal applications with one browser-facing mode.
Warning
A given provider hostname must be inspected at exactly one point. Text survives being inspected twice; image and file uploads do not, because the first pass re-encodes the bytes and the second refuses them.
Limits and known gaps
- Unmanaged devices are out of scope in every mode. Interception needs a certificate authority the client trusts, or software installed on the device. A personal laptop on a home network has neither.
- Certificate pinning defeats interception. A mobile or desktop application that pins its certificate fails to connect through a decrypting proxy rather than being inspected. The remaining control is to block it at the firewall.
- On-device models are invisible. A browser's built-in assistant or a local model makes no network call for any of these modes to see.
- Resumable uploads differ by mode. Behind a third-party gateway the body is reassembled before CID222 is called, so an upload is inspected. In the inline proxy and on the endpoint the fragments arrive as separate requests, cannot be reassembled, and are refused rather than passed through.
- The extension does not block. It has no enforcement of its own; removing it removes the device from the firewall's allow list, which is what denies access.
- Source-address admission is unreliable in a same-host lab. Where a secure web gateway runs as a virtual machine beside CID222, the source network's own address translation rewrites the address and every peer arrives as the container bridge. An address allow list there admits everything or nothing. On a physical network it behaves normally.
Related
- Interception topologies — the same six points in deployment detail, with the decision rules and the failure modes.
- What CID222 is — why a reverse proxy and a forward proxy are not interchangeable.
- Packages and licence tiers — which package unlocks which console.
Last updated on