When an internal application becomes a shared cloud service, a database field such as project_id is not enough to separate customers. Tenant isolation makes each customer’s data, resources, identities, policies, and operations belong to an explicit authorization boundary. section 13.2 section 13.3.1
A tenant receives a globally unique tenant_id, its own namespace for entities, relationships, and policies, and a directory record for ownership, configuration, and identity providers. Every principal, resource, relationship graph, policy bundle, and audit record is scoped to that tenant. section 13.3.1
Effective isolation connects architecture, policy, and operations:
- Centralized policy evaluation replaces service-specific boundary checks and provides consistent decisions and auditability. section 13.2
- Layered authorization separates system, application, and tenant trust domains while supporting federated and hosted identities. section 13.8
- Gateway, service, and user-interface enforcement points can work with policy decision points, graph traversal, partial evaluation, and batch checks. section 13.8
if request.user.company == "ACME" or request.user.project_id == project.id:
allow_access(project)
This legacy check illustrates why a shared project field cannot provide a complete tenant boundary. section 13.2
