Privacy Pipeline
The three steps
Section titled “The three steps”Every prompt passes through three stages before it is sent to the LLM:
Step 1 — Custom Rules
Section titled “Step 1 — Custom Rules”Ki! checks the prompt against any regex rules you have defined in Settings → Custom Rules. These fire first so that project-specific identifiers (e.g. PROJ-[0-9]+, employee IDs, internal codenames) are masked before general NER runs.
Community users can define rules manually per-device. Sovereign users can push rules to all seats via Policy Sync.
Step 2 — Allowlist
Section titled “Step 2 — Allowlist”Before NER runs, Ki! checks each detected candidate against your allowlist. Allowlisted terms — product names, public company names, benign technical jargon — are left unmasked. This prevents over-masking that breaks the coherence of the reply.
Cryptographic Anti-Exfiltration Shield: A common vulnerability in privacy proxies is that LLMs can “guess” the placeholder tokens and trick the system into exposing data. Ki! prevents this entirely. When an allowed term bypasses the engine, it is temporarily swapped with a per-request, randomized cryptographic sentinel (e.g., __KII_a1b2c3d4_0__). Because the sentinel changes every single microsecond, it is mathematically impossible for a compromised cloud AI to guess the token and force an arbitrary unmasking event.
Step 3 — ocultar NER
Section titled “Step 3 — ocultar NER”The final pass uses the ocultar Named Entity Recogniser (an embedded Go sidecar). It detects:
- Names (persons and organisations)
- Email addresses
- Phone numbers
- Dates and date ranges
- Monetary amounts
- Physical addresses
- National ID numbers
Each detected entity is replaced with a typed token: [PERSON_abc3], [EMAIL_7f2a], etc. The token includes a short hash derived from the original value — the same value always maps to the same token within a session, so the LLM can refer to entities consistently.
Community vs Sovereign pipeline
Section titled “Community vs Sovereign pipeline”| Step | Community | Sovereign |
|---|---|---|
| Custom Rules | Up to 10 rules, device-local | Unlimited, policy-synced across team |
| Allowlist | Device-local | Policy-synced, Ed25519-signed |
| NER backend | Built-in local NER | Local SLM (Sovereign) |
Token storage
Section titled “Token storage”Tokens are stored in a local SQLite vault (vault.db) on your device. The vault is encrypted with AES-256-GCM; the key lives in your OS keychain. The vault is never synced to Ki!‘s servers.
Response restoration
Section titled “Response restoration”After the LLM responds, Ki! scans the response for tokens matching the current session’s vault. Each token is replaced with its original value. The process is deterministic — if a token appears multiple times in the response, all occurrences are restored.
If a token appears in the LLM response that is not in the vault (e.g. the LLM invented a token-like string), it is left as-is.