Who and what CID222 trusts — the appliance boundary, the identity model, the access model, and the four places trust is weaker than it looks.

CID222 runs as a virtual appliance inside your own infrastructure. That single fact settles most of its security model: the boundary is the appliance, and everything outside it is either authenticated or admitted by address.

The problem

A gateway that inspects prompts holds, at least briefly, the most sensitive text in the organisation. It also holds the provider credentials that make it useful. Deciding what protects that means being specific about who is inside the boundary, who is at its edge, and where the product believes a claim it cannot verify.

How CID222 does it

The appliance is the boundary, and it is yours

No prompt, reply or detection leaves the appliance for the vendor. The detection models run locally, licence verification is offline against a trust anchor held on the appliance, and the reference catalogues ship inside the image. The only outbound path to the vendor is the optional online update channel, and an air-gapped deployment that never uses it is a supported deployment rather than a degraded one.

The corollary is the honest half: the appliance is a virtual machine on your hypervisor. You own its disk, its memory and its snapshots. There is no vendor-held key protecting the appliance from its own administrator, and there is no remote kill switch. Whoever controls the hypervisor controls the appliance.

Two identities reach the API

Caller	Credential	Notes
A person, through the dashboard	A JSON Web Token (JWT). The appliance ships `JWT_EXPIRES_IN=24h`; a bare compose stack with no `.env` falls back to 8 hours	Signed with `JWT_SECRET`, carrying the tenant id, the username and the role
An application, through the API	A gateway API key, `cid_key_…`	Stored as an unsalted SHA-256 hash; shown once at creation and never again

JWT_SECRET is load-bearing beyond sessions: it derives the keys that protect the stored provider credentials and the directory bind password. The gateway refuses to start on a known placeholder value, and an unset value produces a fresh secret every boot — which invalidates sessions and makes those stored secrets unreadable.

Provider credentials are held encrypted with AES-256-GCM and are never returned by the API.

Access control is enforced by role, not yet by capability

Five roles exist. What is enforced today is the role decorator on each endpoint, plus the page baseline that decides which dashboard pages a role may open.

A 70-capability model is computed and compared on every request, and enforces nothing. It runs in shadow mode so the decorators can be reconciled against it before it becomes policy.

Two roles are worth naming:

viewer satisfies any role requirement on a safe HTTP method and is refused every mutating request globally — a property of the request, not a list of endpoints.
An external auditor reads compliance and governance evidence across every tenant, and cannot read message content. Its one hard exclusion is chat: an auditor holding a session would spend the customer's tokens and write rows into the evidence it is signing off.

Warning

With no capability layer enforcing, an endpoint that carries no role decorator at all is reachable by any authenticated account. This is an accepted property of a decorator-based model rather than an oversight; closing it in general is what the capability phase is for.

The inspection edge is admitted by address

A secure web gateway integrated over the Internet Content Adaptation Protocol (ICAP) is a different kind of caller: not a person, not an application holding a key, but a network peer. It is admitted by source address against an allowlist, and the username it attaches to each request is taken on trust. This is the weakest trust relationship in the product, and the limits below say why.

Limits and known gaps

The ICAP listener cannot authenticate its peer. No secure-web-gateway product CID222 integrates with offers a credential or a custom-header field for ICAP, so admission is by source address alone — and an admitted peer is believed down to the username it claims for each request. Treat the ICAP network path as trusted infrastructure, and put it on a segment where that is true.
Source-IP admission is meaningless in a same-host virtual-machine lab. Where the gateway runs as a VM beside CID222, the source network's own network address translation rewrites the address, and every peer arrives as the container bridge address. A physical gateway on a LAN keeps its address and the allowlist works; a lab VM does not. The listener detects and logs the condition once — read that log before trusting any source-address control.
The allowlist replaces the default, it does not extend it. Setting an allowed-source list removes the private-range default rather than adding to it.
Treat any security-looking field as unenforced until you have found the reader. Two inspection-policy fields were written, displayed and read by nothing until 2026-08-29. Both enforce now, and the upgrade deliberately clears their previous values — because a value that had never been applied would otherwise start rejecting callers unattended.
Gateway API keys have no per-endpoint scope. A key is a tenant-level credential with an optional expiry. A group key additionally borrows the identity of the earliest-added member, so removing that user transfers the key's identity rather than revoking the key.
The audit trail is not tamper-proof. See data handling and retention.
The product cannot defend itself from its own host. The appliance ships as a conventional virtual machine: an administrator with root on the hypervisor can read the disk and the memory. Controls inside the appliance raise the cost of tampering; they do not make it impossible, and no documentation should claim otherwise.

Hardening checklist — the settings that are the operator's job before the appliance carries production traffic.
Data handling and retention — what is on the disk you are protecting.
Access control — assigning the roles described here.

The appliance security model