How is data isolation between tenants technically implemented?
amaise uses a multi-layered logical tenant separation that takes effect as soon as you enter the system:
Entry proxy: the tenant identity is resolved at the earliest point of system entry; the tenant's per-document encryption key is selected from it. Only verified requests with a valid tenant assignment can access that tenant's data, enforced across the whole request lifecycle.
Database (row-level tenant isolation, application-enforced): every record carries a tenant ID and every query is scoped to the authenticated tenant. This is enforced in the application and continuously verified by automated cross-tenant tests in our CI pipeline and code review. Database-native row-level security (Postgres RLS) is planned as an additional enforcement layer. All queries use exclusively parameterized, type-safe methods — SQL injection is therefore prevented by design.
Storage: Document content in S3 is encrypted with tenant-specific KMS keys (CMK). Each tenant has its own document-encryption key, which is assigned already at the entry proxy.
Authorization: Object-based permission checks enforce access controls (ACL) at the level of individual documents, cases, and other entities — including delegation and expiration times.
API: The tenant ID is resolved from authenticated JWT claims. Every endpoint enforces role-based access control.
These permission checks are continuously verified by automated tests; a cross-tenant access attempt is thereby indistinguishable from a request for non-existent data — amaise never reveals whether another tenant's record exists.
Additionally, the regional environments (EU, US, CH) run in completely separate AWS accounts — with no cross-account access whatsoever.