How does Olakai secure customer data and maintain multi-tenant isolation?
Olakai enforces tenant isolation in the application layer: every database query is scoped by account ID, across all repositories, use cases, and server actions, backed by automated tests and query guards. Data is encrypted in transit with TLS 1.2+ and at rest with AES-256, and the practices behind both are backed by an independent SOC 2 Type II examination.
Compliance and certifications
Olakai maintains rigorous security practices across all infrastructure and operations, backed by an independent SOC 2 Type II examination.
Source: Trust & Security
Multi-tenant isolation and access control
Every database query is scoped by account ID. No customer can access another customer's data. This is enforced at the application layer across all repositories, use cases, and server actions, and supplemented by automated tests and query guards.
The design decision worth naming is that isolation does not rest on the discipline of whoever writes the next query. Query guards fail the request, and the automated tests fail the build.
Source: Trust & Security
Encryption standards
All data is encrypted in transit and at rest using industry-standard algorithms.
- Data in transit — TLS 1.2+ on all external connections. HTTPS enforced on all endpoints, with HTTP 80 redirecting to 443.
- Data at rest — AES-256 via AWS RDS for the database and AWS S3 for file storage. AES-256-GCM for sensitive application fields.
- Sessions and credentials — HMAC-SHA256 signed JWTs in HTTP-only, Secure, SameSite cookies. Passwords stored using bcrypt one-way hashing.
Source: Trust & Security
Also asked as
- What are Olakai's security, encryption, and data isolation practices?
- Is Olakai SOC 2 Type II compliant?
- Where is Olakai hosted and how is tenant data separated?