Five layers of isolation. Institution-scoped by construction.
Multi-tenancy is where most education-platform breaches happen. ArthurAI™ is built so cross-tenant data access requires bypassing five independent layers of enforcement. Tenant boundaries are not a configuration flag; they are the architecture.
- 1
Database
Every query that touches institutional data filters by `institutionId`. The institution identifier is part of the query predicate, not the result filter. Repository implementations enforce the filter at the data-access layer, not at the API layer. A query that forgets the filter will not return data — it will return nothing.
- 2
API
The institutionId is extracted from the JWT token on every request, never from user input. A user cannot ask the API for ‘this other institution’s data’; the request is bound to the token's tenant scope before the route handler runs. Authentication and tenant-scoping are inseparable.
- 3
File storage
Tenant-scoped Azure Blob Storage containers, named `tenant-{institutionId}-documents`. SAS tokens for blob access are scoped to the institution at issuance. Cross-tenant blob access requires obtaining a SAS for the target institution — which the API will not issue without authentication into that institution's tenant.
- 4
Cache
Cache keys include the institution identifier as a prefix: `entity:{institutionId}:{id}`. A cache lookup that forgets the institutionId will not collide with another institution's cache; it will simply miss. The Redis cluster is one cluster, but the keyspace is partitioned by tenant by construction.
- 5
Frontend
Every API call from the client carries the institutionId from the auth context, derived from the user's active session. The auth context is established at login and bound to the JWT; switching institutions requires re-authentication. The client cannot fabricate a different institution scope without forging a token, which the API rejects.
Why five layers and not one
Defense in depth. A single layer of enforcement can be bypassed by a single bug. Five layers means a cross-tenant data leak requires bypassing all five — simultaneously, in coordinated failure. We have not seen that pattern in the threat model. Each layer also serves a secondary purpose: the database filter is for query correctness, the API JWT scope is for authorization, the file-storage tenant prefix is for SAS-token scoping, the cache prefix is for partitioning, the frontend auth context is for UX. Isolation falls out of doing each of those well.
What this means for FERPA
FERPA-covered institutions deploy with confidence that education records stay inside the institution's tenant boundary. The platform's architecture supports the school-official posture without relying on application-layer logic that could regress under refactoring. Audit logs are similarly tenant-scoped — an audit reviewer accessing one institution's logs cannot see another institution's.
What this means for procurement
Procurement security reviewers ask the same multi-tenancy questions across vendors: how is tenant isolation enforced, what happens if it fails, who tests it. The five-layer answer is testable; each layer has integration tests that verify enforcement and inject failure cases. The tests run on every pull request; isolation regressions block merges.
See also: security pillars · security FAQ · data handling · Eve-Grid.