# Guardrails

Guardrail layers at the gateway: input masking on every request, response masking optional; prompt injection and hallucination protection coming soon.

Every request that passes through the Gateway goes through guardrail layers before it leaves for the external model. The layers running today are based on masking; two more will be added at the same checkpoint.

| Layer | What it does | Status |
| --- | --- | --- |
| Input masking | Masks personal data inside the request before the model sees it | On (default) |
| Response masking | Masks personal data returned by the model before it reaches the client | Optional |
| Prompt injection protection | Flags inputs that aim to push the model outside the instructions it was given | Coming soon |
| Hallucination protection | Flags model responses that have no grounding | Coming soon |

## Input masking

This is the default layer, and it runs on every request. Text is scanned before it is forwarded to the external model, each detected piece of personal data is replaced with a placeholder such as `<PERSON_1>`, and only masked text goes to the model.

Coverage is 26 categories; the special categories of personal data under Article 6 of KVKK are included. For the full list and synthetic examples see [Categories](/docs/en/categories/), and for the placeholder format see [Concepts](/docs/en/concepts/).

If masking cannot be completed, the request does not go to the external model and the Gateway returns a 502. There is no “send it unmasked anyway” option.

## Response masking

Input is masked on every request; the response side is enabled when the organization requests it. If the model produces personal data in its response or repeats a value from the input, those values are masked before they return to the client.

Streaming is not supported while response masking is on. Such a request is never sent to the model; the Gateway rejects it with 415. In a streamed response the text arrives in fragments and a placeholder can be split across two of them, so letting the stream through quietly would give the impression of protection that is not there. Use the non-streaming endpoints for flows that need response masking.

## Input that cannot be masked

If an input is not text, it cannot be masked and is rejected fail-closed. Today the only case is the embeddings endpoint: the `input` field of a `/v1/embeddings` request may be a pre-tokenized array (token ids). That array is not text; masking it would require decoding it with the provider’s own tokenizer first. The Gateway rejects the request with `415` and never forwards it to the provider. Send text instead.

## Turning masking off

Masking can be turned off per virtual key; requests from that key go directly to the language model, and for that key the Gateway acts as a plain AI gateway. Masked and unmasked keys can run side by side in the same organization.

The organization’s admin makes this call from the panel; staff can see the state but cannot change it. A newly created key always starts masked, and turning masking off requires a separate confirmation. Both turning it off and turning it back on are written to the audit trail together with the key they apply to.

KVKK responsibility

Personal data sent through a key with masking turned off is forwarded to the language model unmasked; for that traffic, responsibility under KVKK rests entirely with the organization. Turn masking off only for keys you are sure carry no personal data; if you are not sure, leave it on.

## Layers coming soon

Two layers are in development. Both are designed to run at the same checkpoint, in the same flow as masking.

**Prompt injection protection.** Flags attempts hidden in user input that aim to push the model outside the instructions it was given. A typical example is an instruction of the “ignore the previous instructions” kind placed inside otherwise ordinary text.

**Hallucination protection.** Flags cases where the model gives an answer with no grounding in a confident tone. This is a different risk from a personal data leak: here the problem is not data going out, but wrong information coming in.

When they go live, this page will be updated and a dated entry will be added to the [Release notes](/docs/en/release-notes/) page.