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, and for the placeholder format see 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.
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 page.