Multitenancy

Tenant source, storage model, isolation guarantee, administrative access, and evolution path interact across every boundary, so one decision records them together before code assumes any of them. The enumeration bound caps how many tenant identifiers an all-tenant record lists.

Reviewed forThe tenant adoption decision under .litespec/intent/decisions/ names source, storage model, isolation guarantee, administrative access, evolution path, and enumeration bound.

Marked guidance: a reviewer answers this question.

Shared tables, separate schemas, and separate databases isolate differently and operate differently: each choice moves work between queries, migrations, backups, and scaling. Naming the model with its guarantee and its operating trade-off tells every later choice which isolation it can rely on.

Reviewed forThe adoption decision names shared-table, schema, or database isolation with its guarantee and operating trade-off.

Marked guidance: a reviewer answers this question.

One part of the product on shared tables and another on separate databases answers which rows each tenant sees two ways. Each mixed model needs its own decision with a data evolution plan, or backup, restore, and incident response each guess which guarantee covers which data.

Reviewed forEach mixed isolation model traces to a decision with a data evolution plan.

Marked guidance: a reviewer answers this question.

The tenant decides which data the request may touch, so only a trusted host boundary resolves it: verified claims, host mapping, or another authenticated source. An identity the caller supplies itself is a choice, not a fact.

Reviewed forEach trusted host boundary resolves the tenant from verified claims, host mapping, or another authenticated source.

Marked guidance: a reviewer answers this question.

A tenant ID taken straight from request data lets any caller name any tenant. Rejecting unrestricted input keeps the request from choosing a data boundary outside its authenticated context.

Reviewed forThe tenant resolver code accepts a tenant identifier only from an authenticated source, never from request data.

Marked guidance: a reviewer answers this question.

Checking the caller alone leaves the target unchecked: an authorized caller can still name a resource from another tenant. The operation confirms both sides through one chain: the actor holds a role at the resolved scope, the role allows the permission, the use case declares that permission in its grant, and the target belongs to the same scope.

Reviewed forThe authorization tests fail a protected operation whose actor and target tenants mismatch.

Marked guidance: a reviewer answers this question.

The tenant scope bounds which tenant data the call may touch: own stays inside the caller tenant, cross reaches across tenants, public works beyond tenant boundaries, and none touches no tenant data. Without the scope, a read inside one tenant and a read across all tenants look the same. litespec/core/access#scope-every-grant-to-its-tenant-reach states the values.

An expense report declares own, a finance search across companies declares cross, a public catalog declares public, and a health check declares none.

Reviewed forEach use case declares own, cross, public, or none in its access tenant scope.

Marked guidance: a reviewer answers this question.

Support and operations sometimes reach across tenants, and that exceptional reach needs exceptional control: a permission held through a role at platform scope, with an audit record for every use. Without both, one support login becomes an unscoped key to every customer's data. Grants that let one tenant act for another follow the delegation extension instead.

Reviewed forEach administrative cross-tenant use case names a platform-scope permission, and the audit trail holds a record for every cross-tenant run.

Marked guidance: a reviewer answers this question.

Session creation is the point that matters: a session opened without a tenant serves an unscoped next query. Resolving the tenant then, through the selected provider's own tenancy support, scopes every query the session runs, so no query carries the concern alone. Adding the filter per query instead leaves every new query one omission away from reading across tenants. The baseline provider resolves the tenant from the registered tenancy at session creation; an Entity Framework Core implementation resolves it when the context is created and applies it through a query filter convention.

Reviewed forThe session-creation code of each provider resolves the tenant through that provider's tenancy support.

Marked guidance: a reviewer answers this question.

Documents, queries, unique constraints, cache keys, outbox records, reactions, jobs, exports, and object-storage paths each form a boundary where tenants meet. Leaving tenant scope out of any one of them discloses or mixes customer data through exactly that gap.

Reviewed forThe documents, queries, constraints, cache keys, outbox records, reactions, jobs, exports, and storage paths in code each carry tenant scope.

Marked guidance: a reviewer answers this question.

A caller that names another tenant's resource forces an answer: pretend it does not exist, or admit it exists and refuse. The product documents one policy and applies it to every cross-tenant response, so callers cannot probe for resources through inconsistent answers.

Reviewed forEach cross-tenant response follows the documented not-found or forbidden policy, shown in the API tests.

Marked guidance: a reviewer answers this question.

Errors, logs, metrics, and traces travel to readers the API never authorized: support screens, dashboards, and log stores shared across tenants. Scrubbing other tenants' identifiers and data from diagnostics keeps the disclosure policy whole past the API boundary.

Reviewed forThe error, log, metric, and trace outputs hold no other tenant's identifiers or data.

Marked guidance: a reviewer answers this question.

Backup, restore, replay, deletion, export, support access, and incident investigation each touch more data than one normal request. Documenting each as one-tenant or all-tenant tells the operator how much data the run touches before it starts.

Reviewed forThe backup, restore, replay, deletion, export, support, and investigation procedures each state one-tenant or all-tenant scope.

Marked guidance: a reviewer answers this question.

A documented scope states what an operation may touch, not what one run touched, and the run is what a tenant asks about after an incident. An all-tenant run is also the one case where no single tenant's audit trail holds the whole event. The OWASP logging guidance treats an administrative action over many subjects as one event to record: actor, operation, reason, tenant count, and reached tenant identifiers up to the adoption decision bound. When the audit extension is selected, the record is an audit record; otherwise it stays a standalone record.

A support export covering every tenant records the operator, the export, the tenant count, and the incident it was run for.

Reviewed forThe record of each all-tenant run names actor, operation, reason, tenant count, and reached tenant identifiers up to the adoption bound.

Marked guidance: a reviewer answers this question.

Delegation lets one actor act for another, so a grant on one side alone leaves the other side unreviewed. The delegator grant names the role at its scope that may be acted for and the permissions open to delegation; the acting grant names the role permitted to act and the pairing it acts under. litespec/core/access#grant-across-tenants-only-through-declared-delegation requires both declarations.

An assistant acts for a manager only where the manager delegation grant and the assistant acting grant both name the pairing.

Reviewed forEach delegation declares a delegator grant naming who may be acted for and an acting grant naming who may act.

Marked guidance: a reviewer answers this question.

A delegation open to every permission hands the whole tenant to the acting party: one pairing meant for reading reports also moves money. Naming each delegated permission bounds the pairing to what the delegator intended, and each new permission needs its own review in the pull request before the acting party holds it.

Reviewed forEach delegation names its delegated permissions, with none open to all permissions.

Marked guidance: a reviewer answers this question.

A grant with no end outlives its reason: the assistant keeps acting after the engagement ends, and nobody reopens the pairing because no date asks for it. An expiry ends the pairing on its date, and a revocation path ends it on demand. Either way, the end is stated beside the grant instead of left for an incident to discover.

Reviewed forEach delegation carries an expiry or a revocation path.

Marked guidance: a reviewer answers this question.

An acted-for action without a marker reads exactly like the delegator's own action, so a reviewer cannot tell who actually acted. Recording the delegation grant used puts the acting party on the record beside the delegator. litespec/ext/audit#record-delegated-administrative-access states the same marker for administrative grants.

Reviewed forEach action under delegation records the delegation grant used.

Marked guidance: a reviewer answers this question.

A pairing described only in prose hides where its grant stops: the allowed assistant and the uninvited one read alike. A scenario walking an allowed call and a scenario ending a call without delegation in the derived forbidden result pin the boundary as checked facts. litespec/core/access#prove-hierarchies-derived-trust-and-delegation-with-scenarios requires both scenarios.

Reviewed forEach delegation proves an allowed call and a refused call with scenarios.

Marked guidance: a reviewer answers this question.