Ki! Trust Center — Privacy-by-Architecture

§1 What Stays on Your Device vs. What Leaves

Every sensitive token is replaced before any outbound network call. The table below is an architectural fact, not a policy promise — you can verify it by reading the source or running a network capture.

✓ Stays on your device

Original prompt text (pre-masking)
All PII / PHI values
Token-to-value mappings (SQLite vault)
Ed25519-signed audit log
LLM provider API key (OS keychain)
Detection engine (Go sidecar — local port 127.0.0.1 only)
Sovereign: local SLM NER model (1.5B params, offline)
Custom masking rules and dictionaries

→ Leaves your network

Masked prompt only — tokens like [PERSON_a1b2] replace all PII
Your configured LLM provider (OpenAI, Claude, Gemini, Mistral, etc.) receives the masked text — never originals
LLM response (streamed back; tokens are re-expanded locally before display)

      Guarantee: Ki! makes exactly one outbound network call per message — to your LLM provider, with the masked prompt. If the masking step fails for any reason (sidecar timeout, detection error, network issue), the prompt is blocked. There is no fallback path that sends unmasked text.
    

§2 Architecture Overview

Ki! is a multi-process sovereign proxy. Three layers run on your machine. The only outbound call is the masked prompt to your LLM provider.

  Your input (keyboard)
        │
        ▼
┌─────────────────────────────────────────────────────┐
│  Layer 1 — React UI (local process)                 │
│  Chat, Vault viewer, Egress log, Settings           │
└──────────────────────┬──────────────────────────────┘
                       │ Tauri IPC (local only)
┌──────────────────────▼──────────────────────────────┐
│  Layer 2 — Rust / Tauri v2 Orchestrator             │
│  ┌────────────────────────────────────────────────┐ │
│  │  1. Custom rules (user-defined regex)          │ │
│  │  2. Allowlist protection (never-mask terms)    │ │
│  │  3. → Ocultar sidecar (POST 127.0.0.1:XXXX)  │ │
│  │  4. Allowlist restore                          │ │
│  │  5. Vault write (SQLite, local disk)           │ │
│  │  6. Audit log entry (Ed25519 signed, append)  │ │
│  └────────────────────────────────────────────────┘ │
└──────────────────────┬──────────────────────────────┘
                       │
        ┌──────────────┴──────────────┐
        ▼                             ▼
┌───────────────────┐       ┌─────────────────────────┐
│  Ocultar Sidecar  │       │  SLM Engine (Sovereign) │
│  (Go binary)      │       │  Local NER model        │
│  Tiers 0–1.5      │       │  Tier 2 AI scan         │
│  127.0.0.1 only   │       │  Offline, on-device     │
└───────────────────┘       └─────────────────────────┘
        │
        │   ← Only if masking succeeded
        ▼
  HTTPS to LLM provider
  (masked prompt only)
        │
        ▼
  LLM response (streamed)
        │
        ▼  Token re-expansion (local, Rust layer)
  Your screen

The Go sidecar binds exclusively to 127.0.0.1 on a random ephemeral port assigned at startup. It is not reachable from the local network, let alone the internet. Your LLM API key is stored in the OS-native keychain — never in a config file, environment variable, or database.

§3 Detection Pipeline

Every prompt passes through an 8-tier cascade. Tiers run in milliseconds on-device. No text is sent to a cloud detection service.

Tier	Method	Examples detected	Availability
0.1	Structured token detection	Base64, JWT, Bearer tokens, API keys in common formats	Community
0	Dictionary lookup	Common first/last names, organisations, cities	Community
0.5	Entropy analysis	High-entropy strings (secrets, credentials)	Community
1	Rule engine	IBAN (MOD97 validated), credit cards (Luhn), 50+ national IDs (SSN, NIF, CPF, PESEL…), SWIFT/BIC, passports, driving licences, tax IDs	Community
1.1	Phone normalisation	Phone numbers in any format/country via libphonenumber	Community
1.2	Address Shield	Postal addresses in EN / FR / ES / DE	Community
1.5	Greeting / Signature	Email salutations and signatures that expose names/contacts	Community
2	Local SLM NER (1.5B params)	Context-aware PII the rule engine misses — clinical notes, legal names in narrative text	Sovereign

The Ocultar detection engine is open source (Apache 2.0). Security teams can audit, fork, or run it independently.

§4 Regulatory Alignment

Ki! is designed to help your organisation satisfy the technical requirements of the following frameworks. Regulation citations below refer to specific obligations that Ki!'s architecture addresses.

Framework	Relevant obligation	How Ki! addresses it
GDPR	Art. 5 (data minimisation), Art. 25 (privacy by design), Art. 32 (technical measures), Art. 83 (fines up to 4% global turnover)	PII never sent to third-party LLM in clear text. Tokenisation is local. Audit log provides Art. 30 processing record evidence.
EU AI Act (Aug 2026)	Art. 10 (data governance for high-risk systems), Art. 13 (transparency), Art. 15 (accuracy and robustness)	Deterministic masking provides auditable evidence of data governance controls. Fail-closed architecture prevents uncontrolled data egress from AI pipelines.
HIPAA	45 CFR §164.514(b) Safe Harbor — 18 PHI identifiers	All 18 Safe Harbor identifiers covered across detection tiers. Audit log provides required evidence of de-identification methodology.
DORA (EU 2025/2553)	Art. 9 (ICT risk management), Art. 16 (incident reporting)	Ed25519-signed audit log provides tamper-evident record of data flows for ICT incident reporting obligations.
NIS2	Art. 21 (cybersecurity risk management measures)	Local processing eliminates a third-party data exposure vector. Fail-closed prevents silent data leakage on system failure.

      EDPB Opinion 28/2025 (April 2025): The European Data Protection Board confirmed that cloud LLMs do not meet the GDPR standard for anonymisation. Pseudonymous tokens (what Ki! sends) are treated as personal data at the LLM provider — but the originals never leave your device. Ki! addresses the architectural root cause, not just the compliance checkbox.
    

§5 Honest Certification Status

We believe security trust is earned by showing what exists, not by listing aspirational logos. Below is our current status, updated as milestones are reached.

Item	Status	Notes
Open source detection engine	✓ Live	Ocultar Refinery — Apache 2.0, auditable on GitHub
Ed25519-signed audit log	✓ Live	Every event signed; hash chain detects tampering
Fail-closed architecture	✓ Live	6 failure modes tested; all block outbound call
SSRF protection	✓ Live	2 bypass vectors found and patched in red-team testing
GDPR DPA template	⏳ On request	Email [email protected] — sent within 48 hours
Penetration test report	⏳ In progress	Targeting Q3 2026; results published here
SOC 2 Type II	✗ Not yet	Planned post-Series A
ANSSI / CSPN certification	✗ Not yet	On the roadmap; not a current claim
ISO 27001	✗ Not yet	Planned post-Series A

§6 GDPR Data Processing Agreement

If your organisation requires a signed DPA before deploying Ki! (required for most EU GDPR Article 28 obligations), we provide a standard template covering the processing activities described on this page.

Request a GDPR DPA

Email us with your organisation name and the jurisdiction of your DPO. We will send a completed DPA template within 48 business hours.

Request DPA via Email

For enterprise deployments using Sombra Gateway (on-premise multi-model router), a separate DPA covering the gateway processing activities is available. Contact [email protected] with subject line "Sombra DPA".

§7 Security Contact

For vulnerability disclosures, security questionnaires, or enterprise security reviews, contact us directly. We respond to all security emails within 24 hours on business days.

Documentation

getki.ai/docs

Running an enterprise evaluation?

We offer 6-week paid pilots (€10,000 fixed scope) for EU organisations preparing for EU AI Act compliance before the August 2, 2026 enforcement deadline. The pilot delivers an integrated Sombra Gateway, configured masking policies, and a GDPR technical evidence report.

Request a Pilot Read Sombra Docs

Privacy is the architecture,not the policy.