Privacy Utility and Credential Safety Validation
Document Type: Security Validation Report Date: 2026-05-20 Release: v0.0520.2 Runtime: Production AIOrouter Canada-resident routing path Scope: Bidirectional PII usefulness plus technical-secret redaction
Executive Summary
AIOrouter passed the credential-safety boundary test: synthetic API-key-like values were not exposed in the model response, and character-level questions about the API key could not be answered.
The tests also showed that personal-name context can remain useful after privacy processing, while downstream LLM reasoning about surname and middle-name semantics may still vary. This report validates AIOrouter's privacy/security boundary, not perfect model reasoning.
Marketing-Ready Claim
PII stays useful. Secrets stay hidden.
AIOrouter is designed for a practical privacy tradeoff: user context such as names can remain useful to the model workflow, while API keys, bearer tokens, passwords, and private-key material are removed before they can be used, echoed, or inspected.
What Was Tested
Two Kilo Code style prompts were submitted through the production AIOrouter path:
| Scenario | Prompt Shape | Purpose |
|---|---|---|
| Chinese travel prompt | Chinese personal names plus a synthetic API KEY ... value |
Verify multilingual name utility and API-key redaction. |
| English travel prompt | Canadian-style English/French names plus a synthetic API KEY ... value |
Verify English name utility and API-key redaction. |
Both prompts asked the model to answer ordinary name questions and secret-character questions, including the third digit of the API key and the fifth-to-eighth characters of the API key.
The public report intentionally omits the full synthetic key-like values. The important evidence is that the live response showed [REDACTED TECHNICAL SECRET] where the key-like value would otherwise have appeared.
Results Matrix
| Test | PII Utility | Technical Secret Safety | Result |
|---|---|---|---|
| Chinese prompt | Names remained available enough for user-facing answer context, with some Chinese name-boundary overmatch observed. | API-key-like value returned as [REDACTED TECHNICAL SECRET]; character-level API key questions could not be answered. |
Security Pass with model-reasoning caveat |
| English prompt | Full name remained visible; surname and middle-name inference were imperfect in the downstream model answer. | API-key-like value returned as [REDACTED TECHNICAL SECRET]; character-level API key questions could not be answered. |
Security Pass with model-reasoning caveat |
Pass Criteria
| Criterion | Status | Evidence |
|---|---|---|
| Raw API-key-like value absent from final answer | Pass | Response used [REDACTED TECHNICAL SECRET]. |
| API key third digit not answerable | Pass | Model reported it could not see the key value. |
| API key fifth-to-eighth characters not answerable | Pass | Model reported it could not see the key value. |
| Person-name context remains usable | Pass with caveat | Names appeared or were restored, but model reasoning over surname/middle-name boundaries varied. |
| Provider echo cannot rehydrate technical secret | Pass | Secret placeholders remain one-way and cannot become the original key-like value in the final answer. |
What This Proves
- API-key-like content is protected before model-provider processing.
- Provider-echoed technical-secret placeholders remain one-way in the final response.
- The model cannot answer secret-character questions because the secret is no longer visible.
- PII templates remain reversible for user-facing context where supported.
- The same privacy boundary works across Chinese and English prompt shapes.
What This Does Not Claim
- It does not guarantee every LLM will infer surnames or middle names correctly.
- It does not claim every natural-language name boundary is perfect.
- It validates AIOrouter's privacy boundary, not the downstream model's semantic accuracy.
Assurance Evidence
| Control | Public Evidence |
|---|---|
| Shared secret-safety policy | The same credential-safety boundary is applied across API prompts and AI/tool content surfaces. |
| Provider-bound protection | Technical secrets are removed from model-provider-visible context before routing. |
| Response-side protection | Technical-secret echoes return [REDACTED TECHNICAL SECRET] instead of the original value. |
| Production release | v0.0520.2 production validation completed on 2026-05-20. |
| Detailed implementation evidence | Retained internally and available to qualified enterprise reviewers under NDA. |
Verification Summary
The release was validated with targeted privacy/security tests, provider-bound wire checks, build verification, API-key leak scanning, and governance validation. Detailed command output and deployment evidence are retained in the internal release record.
Recommended External Wording
Use this wording on public-facing pages:
AIOrouter preserves useful context, such as names in Chinese and English prompts, while preventing credentials from crossing into model-provider context or returning in model responses. In production validation, API-key-like values were reduced to
[REDACTED TECHNICAL SECRET], and the model could not answer character-level questions about the secret.