Multi-tenant cryptographic isolation and strict data boundary controls
How Cura prevents cross-tenant data leaks by enforcing strict multi-tenant boundaries, fail-closed access scopes, and automated continuous CI release gates.
Why application code filtering is not enough
Most health platforms rely solely on software-level query filters. Cura adds an immutable second barrier at the storage enforcement layer.
Single application-layer filter
Relies entirely on software developers remembering to include organization filters on every API endpoint and database query.
- A single developer oversight or query bug can leak cross-patient records.
- Direct database client access or background workers bypass application middleware.
- Omitted filters default to returning all tenant records from the database table.
Dual-tier cryptographic data isolation
Role-Based Access Control (RBAC) middleware + storage-level isolation policies enforced simultaneously on every transaction.
- Storage layer automatically discards records outside the caller’s verified care organization.
- Queries execute in fail-closed mode: missing session context returns exactly 0 rows.
- Automated CI release gates block deployment if cross-tenant leakage is detected.
How multi-tenant isolation protects patient data
Context authorization (per transaction)
- Auth context
- Verified organization scope
- Identity
- Cryptographically signed practitioner token
- Scope
- Active direct care team membership
The session context is bound strictly to the current verified transaction. Connection resets prevent context leakage across requests.
Storage boundary enforcement (fail-closed)
- Enforcement
- Tenant partition isolation gate
- Mode
- Fail-closed (zero-trust default)
- Action
- Cross-tenant records automatically dropped
Even if an engineer writes an un-scoped query, the storage engine returns ONLY records belonging to the authorized care organization.
Automated multi-tenant isolation CI test suite
Security policies are only as good as their automated tests. Cura executes a dedicated multi-tenant isolation test suite in CI on every code commit to empirically verify zero data leakage before any production release.
Cross-org zero rows
Asserts that querying Organization B under Organization A’s session context returns exactly 0 rows.
Carer proxy scoping and consent
Asserts that expired, unverified, or revoked carer proxy accounts and missing GDPR Art. 9 consent receive immediate rejection.
No carer profile creation
Asserts that carer roles cannot execute INSERT queries on the patients table; profiles require clinical provisioning or direct patient verification.
Connection context reset
Asserts that recycled database connections clear session variables without context bleed.
Fail-closed scopes
Asserts that queries executed without explicit session variables fail safely with zero records.
Data isolation and governance FAQ
- Can a carer create a patient profile or access records without explicit consent?
- No. In PostgreSQL Row-Level Security, carer user roles do not possess table permissions to insert records into the patients table. Furthermore, proxy access is gated by active consent (consent_type = "carer_proxy_logging") and verified CarerPatientRelationship records. If consent is revoked or missing, RLS queries return exactly 0 rows.
- What happens if an API endpoint forgets to filter by organization?
- Nothing leaks. Because data isolation is enforced inside the storage engine itself, queries executed in that session strictly return records belonging to the active organization, blocking cross-tenant visibility completely.
- How are covering or locum clinicians granted access?
- Locum clinicians are added to care team memberships with explicit active_from and active_until dates. Once the coverage window closes, the security policies automatically revoke access to the patient roster.