Security and compliance

This guide covers the detection engines themselves, the data CID222 keeps about what it detected, and the mapping from both onto the frameworks you are assessed against.

Detection is CID222's own: custom ONNX models plus a decision-maker that resolves their outputs into one action. Where a threshold decides an outcome, this guide names the threshold and its default rather than describing the behaviour vaguely.

What this guide contains

• Detection pipeline — the order things happen in on the request and on the response, and how competing verdicts resolve.
• PII detection — the entity types, the regular-expression and neural detectors, Turkish-specific entities, and the confidence threshold.
• Toxicity and attack detection — the thirteen toxicity labels and the four attack labels, the threshold files that decide each one, and the evasion decoders that run before all of them.
• Hallucination detection — the response-side check against supplied context, and why it runs in the background rather than on the stream.
• Pseudonymization and masking — how a masked value can be restored, and why the value in a detection record cannot be.
• Data handling and retention — what is stored, for how long, and what is never stored.
• Regulatory mapping — EU AI Act, GDPR, HIPAA and six more frameworks, stated as what the product records rather than as a compliance claim.
• MITRE ATLAS and OWASP coverage — the shipped reference catalogues, and what citing one does and does not assert.
• The appliance security model — the trust boundaries of the appliance itself, and the four places trust is weaker than it looks.

What CID222 does not use

The detection stack does not use Presidio, spaCy, or OPA/Rego. It uses custom ONNX models and CID222's own decision-maker. If you have seen those names attached to this product, they are not descriptions of the code.