I built an AI gateway that keeps Turkish personal data in the cup ☕

The cup and the grounds

When you drink Turkish coffee, the grounds stay at the bottom of the cup. They are called telve. You get what you came for and leave the rest behind.

That is the whole idea behind Telveguard, an open-source gateway I built for enterprise AI usage. The model gets what it needs to do the job. The personal data stays in the company's cup.

The problem is simple and probably familiar. People paste things into LLMs: a customer complaint with a national ID number in it, a bank transfer with an IBAN, a config file with a database password. Applications do the same thing, just faster and at scale. In Turkey, this runs straight into KVKK, the Turkish data protection law, which has strict rules on sending personal data abroad.

I looked at existing AI gateways and guardrail tools. Most are good. Almost none of them understand Turkish data. So I built one that does, and this post walks through the design decisions, the parts I am proud of, and the parts where I broke it myself.

Repo: github.com/osmanuygar/telveguard (Apache 2.0)

Why generic PII detection fails on Turkish data

A Turkish national ID (TCKN) is an 11-digit number. If you flag every 11-digit number, you will mask order IDs, timestamps and phone fragments all day. Users will hate the tool within a week.

The fix is that TCKN, like IBAN and credit cards, has a checksum. A random 11-digit number almost never passes it:

def is_valid_tckn(value: str) -> bool:
    d = [int(c) for c in value if c.isdigit()]
    if len(d) != 11 or d[0] == 0:
        return False
    d10 = ((sum(d[0:9:2]) * 7) - sum(d[1:8:2])) % 10
    return d[9] == d10 and d[10] == sum(d[:10]) % 10

Every identity recognizer in Telveguard validates before it flags: TCKN, tax ID (VKN), Turkish IBAN (mod 97) and cards (Luhn). The tax ID is even stricter. About 10% of random 10-digit numbers pass its checksum by accident, so it only fires when a context word like vergi or VKN is nearby.

The dotted I problem

The second trap is the Turkish alphabet. Turkish has four i's: I ı İ i. Python's str.casefold() turns İ into i plus a combining dot (U+0307). So "TALİMAT".casefold() does not equal "talimat", and a lowercase regex silently misses an uppercase Turkish attack.

The fold function in Telveguard handles this explicitly, and also applies NFKC so full-width and compatibility characters cannot sneak past:

def _fold(text: str) -> str:
    text = unicodedata.normalize("NFKC", text).replace("İ", "i").replace("\u0307", "")
    return text.casefold().replace("ı", "i")

Small detail, but this is exactly the kind of bug an English-first tool never notices.

Why not Presidio?

Microsoft Presidio is great, but importing presidio_analyzer pulls in spaCy and a few hundred MB of dependencies. In the hot path of a security gateway that means latency and supply-chain surface. The core detection engine (telveguard-core) uses only the standard library re. A Presidio adapter exists for teams that already use it.

How it works: mask on the way out, unmask on the way back

Telveguard is a reverse proxy that speaks the same APIs your apps already use. It exposes OpenAI Chat Completions, OpenAI Responses and Anthropic Messages. Adopting it means changing one base URL, nothing else. That includes Claude Code:

export ANTHROPIC_BASE_URL=https://telveguard.company.local
export ANTHROPIC_AUTH_TOKEN=<OIDC access token>

Request flow diagram (embed this image on dev.to)

Every request goes through the same pipeline: identity (OIDC/JWT), scanning, policy, masking. The model name decides the destination. vllm/, qwen or llama models count as internal; gpt-, claude-, gemini- and anything unrecognized count as external.

Internal models get the data as is. External models get placeholders:

what the model sees : Summarize the customer with ID [TCKN_1]
what the user gets  : ...the customer with ID 10000000146...

When the response comes back, placeholders are swapped back to the real values, so the user never sees [TCKN_1]. It also works with tool calls: if Claude Code writes a masked secret into a file via a tool call, the real value is restored in the call that reaches the client.

Scanning is not limited to the user message. The system prompt, tool results (file contents, fetched web pages) and tool call arguments are all scanned. That matters because indirect prompt injection usually hides in exactly those places.

Policy as YAML, and a monitor mode for the nervous

Policy is one YAML file. Rules are evaluated in order and the most restrictive decision wins: block > mask > warn > allow.

rules:
  - name: kvkk-external-mask          # personal data goes masked to external models
    when: { destination: external, entity_in: [TCKN, IBAN_TR, CREDIT_CARD, PHONE_TR] }
    action: mask

  - name: secrets-everywhere-mask     # secrets are masked even for internal models
    when: { entity_in: ["SECRET_*"] }
    action: mask

  - name: intern-tckn-block
    when: { teams: [intern], destination: external, entity_in: [TCKN] }
    action: block
    mode: monitor                     # don't block yet, just log "would have blocked"

The mode: monitor line is the feature I would push hardest in any real rollout. Nobody wants to be the person whose new security tool blocked the sales team on day one. Monitor mode lets you run a rule for a few weeks, see what it would have done, and only then turn it on. A simulator endpoint shows how a single request would be treated without sending it upstream.

Teams come from the OIDC groups claim. If a user is in several teams, a team rule applies if any of them matches. You cannot escape the intern restriction by also joining another group.

Output protection

The response side has its own rules. The interesting part is what counts as a leak: an entity that appears in the output but was not in the input. If a user asks about their own ID and the model repeats it, that is fine. If the model produces an AWS key nobody gave it, that gets masked as [GİZLENDİ:SECRET_AWS_KEY] ("hidden") or the whole response is blocked.

Audit logging follows one strict rule: the raw prompt is never stored. Kafka carries the decision, the entity types, tokens and cost into ClickHouse. That is enough for reporting and dashboards without turning the gateway into the biggest PII honeypot in the company.

I tried to break my own gateway

A security tool you have only tested with friendly inputs is a demo. So I threw a few attacks at the detection engine directly. The test suite passes (227 tests), but tests only cover what you thought of.

Prompt injection detection today is a layer of Turkish and English heuristics, with an optional LLM Guard classifier on top. Here is how the heuristic layer scored (0.85 and above blocks by default):

PII had a similar story. TC 10000000146 is caught, and so is a card number written with spaces. The same ID written as 100 000 001 46 or 100-000-001-46 is not.

None of this is surprising. Regex catches the attacks you wrote down and misses paraphrases. It is still worth showing, for two reasons. First, the honest position for a tool like this is it stops accidental leaks and naive attacks, not it stops attackers. Second, it tells me exactly what to build next:

• Normalize and rescan: collapse spaced-out letters, map leetspeak and homoglyphs, decode Base64/hex blocks, strip hidden HTML from tool output.
• Separator-tolerant IDs: allow spaces and dashes inside TCKN and IBAN before checksum validation.
• Semantic layer: embed a corpus of known attacks with a small multilingual model and compare by cosine similarity. That catches paraphrases regex never will.
• A Turkish injection classifier: translate public injection datasets, expand them with paraphrases from a local LLM, and fine-tune a BERTurk model. As far as I know, nothing like this exists publicly for Turkish.
• An eval CLI with precision and recall in CI, so the next version of this table has percentages instead of anecdotes.

The boring part that legal teams care about most

Engineers like masking. Compliance teams like reports. Since every request is already logged with entity types and destinations, Telveguard turns that into things a data protection officer actually asks for:

• KVKK cross-border transfer report: a monthly CSV of which personal data types went to which foreign AI provider, by team.
• VERBİS draft: detected data types mapped to the categories of Turkey's data controller registry (TCKN → Identity, IBAN → Finance, password → Transaction Security). Legal fields like the transfer basis are deliberately left as "legal will decide".
• AI inventory and EU AI Act classification: teams declare their AI systems in YAML. The key idea is that the use case sets the risk class, not the model. The same model is limited risk when it answers customer questions and high risk when it screens job applicants.
• Undeclared usage: team × model combinations seen in the logs that match no declaration. This is how you find the AI usage nobody told you about.

All of these are drafts, not legal advice. The final call stays with the legal and compliance team.

Shadow AI: the browser extension

A gateway only sees traffic routed through it. The employee who pastes a customer list straight into ChatGPT in a browser tab never touches it. For that case there is a Chrome/Edge extension (Manifest V3).

It scans text pasted into AI chat sites locally, using a JavaScript port of the detection engine. CI runs both engines on the same fixtures and fails if the JS and Python results ever differ. In warn mode the user gets three options: paste masked, cancel or paste anyway.

Only the site, the counts per entity type and the user's choice are reported. The text itself never leaves the browser. Logging site visits is possible but off by default, because that is employee monitoring and needs to be communicated first.

Try it in two minutes

You only need Docker. No real LLM is required: the test setup uses a mock model that echoes back what it received, so you can see the masking with your own eyes.

git clone https://github.com/osmanuygar/telveguard && cd telveguard
docker compose -f docker-compose.yml -f docker-compose.test.yml up -d --build

curl -s localhost:8080/v1/chat/completions -H 'content-type: application/json' \
  -d '{"model":"gpt-4o","messages":[{"role":"user","content":"TC 10000000146 olan müşteriyi özetle"}]}'

The mock shows [TCKN_1] in what it received, and the response you get back has the real number restored. The usage dashboard is at localhost:8080/xray.

For production there is a Helm chart that runs under OpenShift's restricted-v2 SCC (no root, read-only filesystem), OIDC auth on by default, Prometheus metrics, per-team quotas and an air-gapped install path where every model is mirrored locally ahead of time.

What I'd love feedback on

Telveguard is at v0.2 and very young. A few questions I'm genuinely unsure about:

1. Detection vs. mitigation. Should the next effort go into better injection detection (the classifier), or into mitigation like spotlighting untrusted tool output and taint-tracking agent sessions?
2. Mask or route? When sensitive data shows up, masking sometimes breaks the task ("which bank is this IBAN from?"). Would you rather the gateway reroute the request to an internal model automatically?
3. Turkish attack data. If you have Turkish jailbreak or injection examples, or know of a dataset, I'd like to build a public benchmark.
4. Non-Turkish use. The core is built around country-specific recognizers. Would a pluggable "locale pack" for other countries' IDs be useful to you?

Issues, PRs and harsh reviews are all welcome: github.com/osmanuygar/telveguard.

Afiyet olsun. ☕