A practical distinction between carrying a tenant ID and deciding whether a caller may use it.

The problem: a tenant ID can arrive correctly and still be wrong

Consider a synthetic application where Alice belongs to tenant-a and Bob belongs to tenant-b. Alice sends a request with x-tenant-id: tenant-b . Middleware copies that value into AsyncLocalStorage (ALS). A repository reads the context and filters its query by tenant-b.

The context propagation can work exactly as designed while the application returns the wrong tenant's data. The missing step is membership authorization. This is a hypothetical failure path, not a report of a real incident.

ALS is useful here. The mistake is assigning it responsibility for deciding whether the selected tenant is allowed. A tenant identifier in a store is a value supplied by application code. Its presence does not establish its provenance.

Constraints and trust boundaries

This article uses fake identities, memberships and rows.…