Defines tenant isolation as an end-to-end invariant across identities, database queries, object storage, search, caches, queues, exports, logs, and administration, with deny-focused verification.
Package status: reference context ready for human review. The contract and test scenarios are complete, but no claim is made that an adopting implementation has passed them.
Decision
Resolve tenant context from authenticated membership and enforce it at every data boundary. Never trust a client tenant identifier by itself; bind resource identity and authorization to the resolved tenant and fail closed on missing context.
Scope
- Tenant context, memberships, resource ownership, database, storage, cache, search, background work, export, analytics, logs, support tools, and tests.
- Shared infrastructure serving multiple customer organizations.
- Control evidence and incident signals.
Outside this block
- Dedicated-infrastructure tenancy as the only valid architecture.
- Using hard-to-guess IDs as isolation.
Contract
- Authenticated subject plus selected membership yields one request tenant context; every resource access checks ownership against it.
- Database access applies tenant predicates structurally, with row-level controls or repository guards as defense in depth.
- Cache, rate-limit, idempotency, cursor, and lock keys include tenant and environment.
- Object keys, search documents, vector queries, queues, and job payloads carry tenant context verified against ownership records.
- Aggregate counts, existence errors, logs, traces, exports, backups, and support views cannot reveal another tenant through indirect behavior.
- Privileged cross-tenant operations use separate capabilities, reason, bounded scope, expiry, and audit.
Implementation guidance
- Create typed tenant context that cannot be constructed from arbitrary request fields in domain code.
- Require data-access APIs to accept context and make unscoped calls unavailable to ordinary application code.
- Use synthetic tenant-pair tests across each storage and serving layer.
- Inspect tracing and metrics dimensions to avoid high-cardinality or sensitive tenant leakage.
Failure handling and safeguards
- Missing or conflicting tenant context denies access and emits a correlation-safe security event.
- Background messages with invalid tenant ownership enter quarantine; consumers do not guess.
- Support impersonation ends on expiry or actor/session change and displays a persistent banner.
Verification and operations
- Measure cross-tenant denial, missing context, ownership mismatch, privileged session use, unscoped-query detection, and synthetic isolation probe results.
- Run deny tests after schema, index, cache, or job changes.
- Treat any confirmed cross-tenant disclosure as a security incident with preserved evidence.
The executable-looking examples in this package are fixtures and acceptance contracts. Run
python tools/validate.py from the collection root to check package structure and metadata; then
implement and execute the scenarios in the target repository.
Adoption assumptions
- Names and numeric values in
example.yamlare an adoption profile, not universal defaults. - The adopting team must map actors, data classes, error vocabulary, and ownership to its system.