What CID222 is

CID222 is an AI gateway you run on your own infrastructure. It sits between the people and applications in your organisation and the large language models they use, inspects what crosses in both directions, applies your policy before the provider sees the request and before the answer reaches the user, and records every verdict against a named account.

The problem

A model provider sees whatever is sent to it. Once a prompt has left the network there is no recall, no redaction and no audit trail: the customer record, the private key or the internal architecture in that prompt now lives in someone else's logs and possibly in someone else's training set. The two obvious responses both fail. Blocking model providers outright stops work that the business has already decided it wants. Allowing them outright means nobody can answer the two questions an auditor asks — what left, and who sent it.

The traffic is also not in one place. It arrives three different ways:

• an application or script calling a provider's API,
• a person typing into a provider's website in a browser,
• a desktop or command-line tool speaking its own protocol.

Each of those terminates somewhere different, so a control that covers one of them leaves the other two untouched.

How CID222 does it

It is the endpoint, or it is behind one that decrypts

For application traffic, CID222 is the destination. An application changes its base URL, CID222 holds the provider credential, and the provider is never addressed directly. For browser and desktop traffic, CID222 is either the forward proxy that decrypts the session with its own certificate authority, the scanner an existing secure web gateway calls over ICAP, software on the device, or a browser extension that reads content before it is encrypted at all. Six interception points, one policy — see deployment modes.

It inspects both directions

Every prompt is decoded for evasion, then five detectors run over it in parallel: personally identifiable information by pattern and by neural model, toxicity across thirteen labels, prompt injection and jailbreak, a deterministic SQL-injection and cross-site-scripting scan, and code safety where the content is code. A validation layer confirms or demotes each finding and a single decision maker turns them into one action: reject, mask, or flag. The reply is scanned again for information leakage and toxicity before any of it reaches the user, and a background check scores it for hallucination against supplied context. See detection engines at a glance.

It attributes and records

Every verdict is attributed to a tenant and written to the database, so the same appliance answers "was this blocked?" and "who has been sending this?". Repeated jailbreak and injection detections against one user fill a sliding window that opens a review by a local risk-analyst model. Detections and events export to your security information and event management system.

It runs where your data already is

CID222 is deployed on infrastructure you control: a Docker Compose stack, or a virtual appliance image that carries every model inside the image. There is no hosted control plane. An air-gapped appliance is fully functional, licence verification included, because a licence is a signed file rather than a call to a licence server. Detection models are CID222's own — the stack does not call a third-party classification service to make a decision about your text.

It is multi-tenant

One deployment serves many tenants — customers, departments, service accounts — each with its own sign-in, its own provider credentials, its own data, and a policy that can differ from everyone else's. See multi-tenancy.

What CID222 is not

This section exists so that a deployment is planned against the product rather than against a category name.

It is not a way to break TLS. Reading browser traffic to a provider's website requires decrypting a session the browser negotiated with someone else, and that requires a certificate authority the client already trusts. On a device your organisation manages, installing that authority is a normal, well-understood administrative act. On a device you do not manage it is not possible at all, and no configuration of CID222 changes that.

A reverse proxy is not a forward proxy. Putting CID222 in front of your own application governs what that application sends. It does not intercept a browser going directly to a provider's website. Those are different deployments with different prerequisites, and the second one is not a setting on the first.

It is not an unsanctioned-use control on unmanaged devices. An employee on a personal laptop at home, on their own network, is outside every interception point CID222 offers. So is a mobile application that pins its certificate, and so is a model that runs on the device itself — a browser's built-in assistant makes no network call to intercept.

It is not a model provider. CID222 does not host the models your users talk to; it holds the credential and governs the conversation. The one model it runs for itself is the optional local risk-analyst, which reads detections rather than user traffic.

It is not a general-purpose data-loss-prevention product. It inspects the AI traffic that reaches one of its interception points. Email, file shares, removable media and everything else remain the job of the controls you already have.

It is not a spend control. Token usage and cost are counted and reported after the fact. There is no per-tenant quota that stops a request because a budget was reached, and no rate limit on the chat, detection or analysis endpoints.

It is not a certification. The compliance and governance features map what CID222 observed onto regulatory frameworks and produce evidence. They do not make an organisation compliant, and no number this product prints is an assessment.

Limits and known gaps

• Interception is only as good as the trust anchor. Where CID222 or a gateway decrypts, the client must trust the decrypting authority. A certificate-pinning application fails closed and is visible as a broken application, not as a silent bypass — but it is not inspected.
• Chunked and resumable uploads are refused, not inspected. No path buffers a request body across requests, so a fragmented upload cannot be reassembled and scanned. Since 2026-08-29 all three paths refuse them by default rather than passing uninspected bytes. The user sees a refusal, not a redaction.
• The stream is not incremental. Output filtering runs on the complete reply, so a client waits for the whole generation and then receives it in one event. Interfaces that expect token-by-token rendering look frozen and then jump.
• The ICAP listener cannot authenticate its peer. No secure web gateway CID222 integrates with offers a credential field, so admission is by source address alone, and an admitted gateway is believed down to the username it claims.
• Accuracy numbers are conditional. Detection quality depends on text length, language, which detector fired and how the filter is configured. Treat any bare percentage as unverified and read the qualified figures in the performance and accuracy reference.

Related

• Deployment modes — the six interception points and what each one sees.
• Architecture — the components, the services and the path a request takes.
• Packages and licence tiers — what each package includes.