# Validate Tenant Context On Tenant-Scoped Writes

Keeps a tenant id mandatory on every write that belongs to one tenant, checked in the service.

Follow these project instructions.
# Validate Tenant Context On Tenant-Scoped Writes

Keeps a tenant id mandatory on every write that belongs to one tenant, checked in the service.

Version: `1.0.0`

A tenant-scoped write needs a tenant, and the service is where that is settled. IBeam refuses the operation when no tenant can be resolved for an authorized service call, and the generic repository base refuses a tenant-specific read or write when no tenant is set. Treat both as a backstop rather than the design: the service should have established the tenant before either is reached.

Take the tenant from the caller's context, not from the request body. A tenant id a client can send is a tenant id a client can change, and every multi-tenant leak starts with trusting one.

Never make the parameter optional to get a compile or a test to pass. A nullable tenant on a write path means the check has been moved to runtime, where it becomes an exception in production instead of a refusal at the boundary.

Two places the guarantee thins out: base CRUD demands a tenant on writes but not on reads, and none of it runs when no authorizer is registered. A read path returning another tenant's rows is as much a leak as a write, so filter by tenant in the query rather than relying on the demand.

#### Constraints
- Do not make a tenant id optional on a tenant-scoped write.
- Never assume a read is tenant-filtered because writes are checked.
- Never read the tenant id from a request body or a client-supplied parameter.

#### Verification
- A request naming another tenant is refused, proven by a test
- Every tenant-scoped write resolves its tenant from the caller’s context
- Read paths filter by tenant in the query itself