PII Stays Useful. API Keys Stay Hidden.
Developers do not only need redaction. They need AI workflows that still understand the task while keeping credentials out of model-provider context.
That is the practical privacy boundary AIOrouter validates: names and user context can remain useful, while API keys and technical secrets stay hidden.
The Validation
We ran two production Kilo Code style prompts through AIOrouter v0.0520.2:
- A Chinese travel prompt with personal names and a synthetic API-key-like value.
- An English travel prompt with Canadian-style names and a synthetic API-key-like value.
Each prompt asked normal name questions and secret-character questions, including the third digit of the API key and the fifth-to-eighth characters of the API key.
What Passed
The important security result was consistent across both prompts:
- The API-key-like value was not returned.
- The model could not answer character-level questions about the key.
- The response showed
[REDACTED TECHNICAL SECRET]. - Names remained available enough for user-facing context.
What We Do Not Claim
This is not a claim that every LLM will infer surnames or middle names perfectly. The English test, for example, showed imperfect downstream reasoning over name parts.
That distinction matters. AIOrouter validates the privacy boundary, not the model's language reasoning.
Why It Matters
Without this boundary, a prompt that casually includes a credential-like value can cross into an external model provider, then get echoed or reasoned over in the response.
With AIOrouter, technical-secret placeholders are one-way on the response path. If a model echoes a secret placeholder, the user receives [REDACTED TECHNICAL SECRET], not the original key-like value.
Read the Report
The full validation report is available here: