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 recogniser weights are operator-controlled only: KINDI never loads weights supplied by a customer or by an untrusted source.

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; we prefer TLS 1.3 where the client supports it. Internal service-to-service traffic is on a private network segment and additionally authenticated.

Compute, primary database, Redis cache, backups, and operational logs all run on a single in-Kingdom virtual private server in the Riyadh region. Backups are encrypted at rest and held in the same region. KINDI does not move personal data outside the Kingdom in the course of normal operation. The two non-KSA sub-processors (DNS and transactional email) receive only what is described on the Subprocessor 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. Access reviews run quarterly.

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 the recogniser-side static checks the same masking recognisers apply to customer text.

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 three CycloneDX 1.5 SBOMs on every release: one for the Python service, one for the dashboard/admin workspace, and one for the marketing site. The SBOM generators are version-pinned for byte-reproducibility. SBOMs are attached to GitHub Releases and 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 Controlsfor 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 publish a running status update at status.kindi.me. A post-incident review is published within fourteen calendar days of resolution.

Security researchers may write to security@kindi.me with reproducible findings. 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.