Security

Personal data is masked before it reaches the model. Fail-closed behavior, no data retention, infrastructure hosted in Turkey, and the audit trail.

Personal data is masked in Turkey before it goes to the external language model; the rest of the security model exists to keep that sentence true. On this page you will find what happens when something fails, what is not stored, and who can access the panel and how.

Personal data is masked before it reaches the model

Every request passes through the masking step before the language model is called. Only masked text goes to the model; detected values are replaced with placeholders such as <PERSON_1>. See Concepts for the placeholder format.

Response masking (output guardrails)

Input is masked on every request. If the organization requests it, the response side is enabled as well: if the model produces personal data in its response or repeats personal data from the input, those values are masked before they return to the client. The feature does not change the default behavior. It is not applied to streaming responses: to avoid breaking the real-time stream, the response passes through as-is, and this is recorded in the audit trail.

If masking cannot be performed, the request stops

Masking works fail-closed: when masking cannot be completed, the request does not go to the external model, the Gateway returns a 502, and the original text is not forwarded either. When in doubt, the request does not pass. The details of this behavior are on the Concepts page.

Masking on/off (passthrough)

Masking is on by default, and that is the usage we recommend. If the organization wishes, masking can be turned off for a specific virtual key; requests from that key go directly to the language model, and for that key the Gateway acts as a plain AI gateway. The setting is per key: masked and passthrough keys can run side by side in the same organization. It is changed from the panel and takes effect immediately; masking stays on for every key unless you turn it off.

No data retention

Raw personal data is not stored permanently. The mapping (vault) that makes it possible to go from a placeholder back to the original value is off by default; it is produced only when explicitly requested and is not logged.

Data sovereignty

Masking runs on infrastructure hosted in Turkey and before the model call. The platform and the masking model are hosted on DT Cloud servers in Istanbul. Only masked text goes to the model abroad; raw personal data is processed in Turkey and stays there.

For organizations that want to run the infrastructure entirely on their own systems, an on-premise deployment option is also available; for details, contact us.

Audit trail

Administrative events (sign-ins, MFA setups; key generation, rotation, and revocation; user and quota changes) are written to an append-only audit trail. Records are not modified after the fact; only new records are added to the trail, and the trail can be exported as CSV or Excel. For masking events, metadata such as category and detection count is kept; the trail contains no surface text, and the masked text itself is not recorded.

Access security

Signing in to the panel requires email, password, and a mandatory TOTP code; permissions are role-based. Traffic is encrypted with TLS. The language model provider’s real key stays inside the Gateway only; the panel and clients work with virtual keys. See Panel for the panel steps.

Masked categories

Masking covers 26 categories; alongside general categories such as name, TCKN (Turkish national ID number), and IBAN, the special categories of personal data under Article 6 of KVKK are also in scope. See Categories for the full list and synthetic examples.