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

Input is masked on every request; if the organization requests it, the response side is enabled as well and personal data returned by the model is masked before it reaches the client. The details and the streaming exception are on the Guardrails page.

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; the setting is per key and takes effect immediately from the panel. For keys with masking turned off, responsibility under KVKK (Turkey’s personal data protection law) rests entirely with the organization. See Guardrails for details.

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.