PII Masking

Configures how personal data in this project’s conversations is detected and replaced with tokens (e.g. <EMAIL_a1b2c3d4>) before it reaches the LLM and before it’s written to the database. The original value is restored in the response sent back to the end user, and in the parameters your tools’ actions deliver to their destinations (tool endpoints, webhooks, notification emails) — action logs keep the redacted (token) form, not the original value.

Compliance template

Every project rides on a compliance template that bundles a set of patterns. If you haven’t chosen one, the project defaults to the KVKK Baseline template. Pick a different template from the dropdown at the top of the page.

Pattern policies

Each pattern in the active template has a policy:

To remove a Recommended pattern, click Remove, then confirm in the dialog that the exemption is approved — the removal is recorded on the audit trail. Removed patterns can be restored at any time. Hard patterns have no remove control.

To add a pattern that isn’t part of the active template, use the Add an existing pattern picker under the pattern list.

Custom patterns

Define patterns specific to this project (for example, an internal order-number format) with Add custom pattern: a slug (used inside the masking token, e.g. <ORDER_NO_...>), a display name, a regular expression, and the replacement token. Custom patterns are validated server-side — an invalid regex is rejected when you save.

Notes

A free-text Notes field records the reasoning behind your template and pattern choices, for your own audit trail.

What isn’t masked

Masking applies to the message text and to tool results, not to the context values your app sends with a request — those reach the LLM as-is. Keep PII out of context and use endUserData instead, which is never sent to the LLM unless a tool’s Description references it with {{endUser.*}}. See Context for the difference between context and endUserData.