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 network peering between them. Customer data never crosses an account boundary; a small number of named administrative roles are assumable from amaise's central account for operations, and every such assumption is logged.