KINDI’s threat model treats every HTTP endpoint as untrusted input, every customer-supplied byte as potentially adversarial, and every operator-side compromise as worth mitigating in advance. It assumes that a competent attacker may, at some point, gain access to a single component of the stack; it is designed so that even in that event, the body of customer requests cannot be recovered.

ML checkpoints and detection-model weights are operator-controlled only: KINDI never loads weights supplied by a customer or by an untrusted source.

One limit belongs at the top of this page rather than at the bottom. Detection is a statistical system evaluated against a fixed benchmark, not a proof. KINDI is a strong technical safeguard, not a guarantee that no identifier survives masking; residual risk stays with the Controller.

KINDI can forward a masked request to a frontier language model on your behalf, so the mask, the forward, and the unmask all happen in one in-Kingdom request. The proxy reaches only an explicit allowlist of provider hosts, currently OpenAI and Anthropic; a request to any other host is refused before any network call is made. Only masked text is forwarded: the personal-data spans are replaced with deterministic placeholders first, so the original personal data never leaves the Kingdom. On the bring-your-own-key path, your provider key is passed through for the single request and is never stored. The placeholder mapping lives in the request only and is discarded once the response is returned.

Every masking request produces a single-use data-encryption key (DEK). The DEK encrypts the placeholder-to-original mapping under AES-256-GCM. The DEK itself is then wrapped under a key-encryption key (KEK) derived from the requesting API key by HKDF-SHA-256. The wrapped DEK and the ciphertext travel together in the response envelope; the API key never leaves the customer.

The consequence: KINDI can produce an envelope, but it cannot read one. Only a holder of the API key can. When an API key is revoked, every envelope previously issued under it becomes structurally undecryptable. There is no operator override and no key-escrow path.

Transport is TLS 1.2 or later; TLS 1.3 is negotiated where the client supports it. Internal service-to-service traffic is on a private network segment and additionally authenticated.

All compute, storage, and backups operate within the Kingdom of Saudi Arabia (Riyadh region), secured with encrypted transport and encryption at rest. Backups are held in the same region. KINDI does not move personal data outside the Kingdom in the course of normal operation. Four sub-processors operate outside the Kingdom: DNS and TLS issuance, transactional email, and the two language-model providers the optional proxy reaches on your instruction. Each receives only what is described on the Sub-processor List.

Production administrative access requires a second factor (TOTP), is granted on a least-privilege basis, and is recorded in a centralised audit log. The admin console lives on its own subdomain under its own session cookie; the customer session cookie has no authority over any admin endpoint. Administrative access is reviewed on each role change and at least annually.

Production logs never carry request bodies, response bodies, bearer tokens, password reset tokens, or email addresses at the INFO level or above. Only identifiers (account ID, key ID, request ID) travel up the log pipeline. This is enforced by code review and by static guard tests in CI that fail the build on a forbidden log call.

Every pull request runs a HIGH-or-above dependency-audit gate (pip-audit on Python, pnpm audit on the frontend), and a weekly scheduled run repeats the check independent of merge activity. A pre-push git hook runs the same audit locally. Residual unfixed CVEs are tracked in a top-level SECURITY.md with a threat-model justification per entry. Dependabot opens pull requests on every upstream advisory; auto-merge is off, so every dependency change is reviewed by a human.

KINDI emits six CycloneDX 1.5 SBOMs, on every pull request to the release branch and on every release: one for each of the three Python services (the gateway, the detection service, and the file worker), one for the dashboard and admin workspace, one for the marketing site, and one for the developer documentation site. The SBOM generators are version-pinned for byte-reproducibility. SBOMs are available on request to customers conducting their own supply-chain review.

KINDI’s security architecture is designed to align with the controls published by the National Cybersecurity Authority:

• Essential Cybersecurity Controls (ECC-2:2024) for the baseline security posture of the service.
• Cloud Cybersecurity Controls for the service-tenant relationship with KINDI’s hosting provider.
• Data Cybersecurity Controls (DCC-1:2022) for the handling of data at rest, in transit, and at the boundary.

These are alignment statements. KINDI has not yet undergone a third-party attestation against any of the three frameworks. This page will be updated, and the corresponding statement on /trust will be updated, when an attestation is in hand.

On a confirmed material incident affecting customer data or service availability, KINDI will notify the registered account email within 72 hours of confirmation, will notify the SDAIA breach-notification service within the same window where personal data is affected, and will send running status updates to the registered account email until resolution. A post-incident review is provided to affected customers within fourteen calendar days of resolution.

Security researchers may report reproducible findings through the contact form, selecting the security topic. KINDI acknowledges within one business day, gives an initial assessment within five business days, and works with the researcher on a coordinated disclosure timeline. A machine-readable contact is also published at /.well-known/security.txt.