trust center
Security
Divelai asks you to route sensitive data through it. That is a large request, and it deserves specifics. This page describes how the system is built and operated: where data goes, how it is protected, and what happens when something goes wrong.
Where data is processed and stored
Payloads
Request and response bodies are processed in memory and are not written to disk. Divelai does not retain payload content after a request completes. Self-hosted deployments never send payloads outside your infrastructure at all.
The token vault
Token-to-value mappings are the only sensitive data Divelai stores. The vault is encrypted with per-tenant keys, isolated from the processing path, and pinned to a region you choose. On the self-hosted plan it runs in your own database and Divelai has no access to it.
Audit records
Logs hold detector, transform, token, policy version, destination, and a keyed hash of the original value. Original values are never written to logs. Audit records are kept for 12 months by default, and the retention window is configurable per deployment.
Encryption
TLS 1.3 in transit with HSTS preload. AES-256 at rest. Encryption keys are held in a managed key management service, never stored alongside the data they protect, and rotated at least annually.
Tenant isolation
Hosted deployments are logically isolated: every record is scoped to a tenant at the data layer, and each tenant’s vault is encrypted with its own keys. Private cloud and self-hosted deployments are single-tenant by design.
Access control
Production access is limited to a small number of named engineers, requires single sign-on with multi-factor authentication, is granted for a specific task, and is logged. No one at Divelai has routine access to vault contents; emergency access is logged and reviewed.
Security reviews
Send your security questionnaire with your enquiry. We would rather answer it at the start of your evaluation than at the end of a procurement cycle.
| Item | What you get |
|---|---|
| Security questionnaire | Completed in full during a review, under NDA if you prefer |
| Architecture walkthrough | Written data-flow and data-handling documentation, plus a call with an engineer |
| Data Processing Addendum | Pre-signed, with subprocessor categories listed |
| Software bill of materials | Available on request |
| Subprocessor list | Current list |
Reporting a vulnerability
Report findings through the contact form, choosing Security review. Include enough detail to reproduce. We acknowledge within one business day and will keep you updated until the issue is closed.
Test only against accounts and data you own. We will not pursue legal action against researchers who act in good faith, stay within their own tenant, avoid degrading service for others, and give us reasonable time to fix an issue before disclosing it.
Machine-readable contact details are at /.well-known/security.txt.
If something goes wrong
If we confirm an incident affecting your data, we notify you without undue delay and within 72 hours: what happened, which data was involved, what we have done, and what you should do.
Backups are encrypted and restores are tested. Our recovery targets are a recovery point objective of one hour and a recovery time objective of four hours.
Dependencies are scanned for known vulnerabilities on every change, production builds come from reviewed code in version control, and a software bill of materials is available on request.
Security review questions welcome.
Send your questionnaire. We would rather answer it early than at the end of a procurement cycle.