Search docs
Docs searchValidation category
Tenant Isolation
Review implemented validation rules for tenant context propagation, tenant-scoped data access, and tenant-model documentation.
Tenant Isolation findings protect organization-scoped Cloud data by checking that tenant context and enforcement remain visible.
Overview
Review implemented validation rules for tenant context propagation, tenant-scoped data access, and tenant-model documentation.
Tenant Isolation findings protect organization-scoped Cloud data by checking that tenant context and enforcement remain visible.
Why it matters
Cloud uses this guidance to help teams interpret local validation findings in organization context without turning the docs into implementation notes.
When this domain drifts, findings become harder to triage, ownership becomes less clear, and architecture review depends too much on individual memory.
Good architectural practices
- Tenant or organization context carried through request workflows.
- Data access constrained by tenant scope.
- Tenant isolation decisions documented for reviewers.
Common anti-patterns
- Missing tenant context propagation
- Missing tenant enforcement on data access
- Cross-tenant access risk
- Tenant isolation model undocumented or inconsistent
Relationship to other architecture areas
This domain usually overlaps with neighboring validation categories. Use the related pages below to understand the adjacent architecture concerns before changing policy, suppressing a finding, or accepting risk.
Implemented rules
These are the currently implemented rules in this category. Use this table for category-level orientation, then open the Rule Catalog when you need rule-specific examples and remediation guidance.
| Rule ID | Rule title | Category | Severity | Short explanation | Example violation | Remediation guidance | Rule detail |
|---|---|---|---|---|---|---|---|
| AP-TEN-001 | Missing tenant context propagation | Tenant Isolation | warning | Flags request or workflow paths where tenant context is not clearly propagated. | createRepository(input) writes repository data without organizationId in the service call. | Pass tenant context through service and repository method signatures. Use explicit scoped inputs for tenant-sensitive work. Add tests that prove the tenant context reaches data access. | View rule page |
| AP-TEN-002 | Missing tenant enforcement on data access | Tenant Isolation | warning | Flags data access without clear tenant-scoping enforcement. | findUnique({ where: { id: repositoryId } }) for an organization-scoped repository. | Add tenant constraints to the query. Require tenant scope in repository inputs. Review raw SQL and ORM calls for tenant filters. | View rule page |
| AP-TEN-003 | Cross-tenant access risk | Tenant Isolation | warning | Flags flows that may combine or expose data across tenant boundaries. | A repository activity query aggregates all organizations for a member-scoped dashboard. | Constrain the flow to one tenant. Add explicit administrative authorization for cross-tenant operations. Document and test any intentional global access path. | View rule page |
| AP-TEN-004 | Tenant isolation model undocumented or inconsistent | Tenant Isolation | info | Reports missing or inconsistent documentation for the tenant isolation model. | The schema uses organizationId everywhere, but the architecture overview never describes tenant isolation. | Update the tenant model ADR or architecture overview. Name the tenant discriminator and ownership model. Link tenant isolation docs from security-sensitive workflows. | View rule page |
Related pages
Next steps