Multi-tenant isolation

Verifies

Requires an AI engine: In a multi-tenant application every read and write on shared stores is scoped to the session tenant, explicitly or through a global mechanism, and the tenant is never taken from the client.

Inputs

Non-test code files of the checkout (JavaScript, TypeScript, Python, PHP) plus Prisma and SQL schemas. Tenancy is detected by tenant, organisation, workspace, account, company, team or site identifiers in schema files; global mechanisms by ORM middleware, plugins, managers, global scopes, tenancy packages and row-level security. Handler files (unscoped first) and schema files (at most 24, first 96000 characters each, chunks of 16000) are sent line-numbered to the chosen engine through the platform ai service; at most 160000 estimated tokens per execution. Paths listed in excludes (test, spec and tmp files, __tests__, __mocks__, fixtures, test, tests and audit-scripts folders) are never analysed. Every model call (rubric, repository context and files) stays under 120000 characters; a candidate set that does not fit is sent in parts, each part bounded by what the chosen engine serves in one call (the engine publishes that budget; a call is never filled up to the transport cap).

Decision rule

Not applicable without tenancy, or when no HTTP handler accesses tenant-scoped data. FAIL (HIGH) when a handler takes the tenant identifier from the request body, query or params. Raw SQL on a tenant-scoped table without a tenant column is MEDIUM (blocks in this Extended suite). Handlers without a tenant key in the window and without a global mechanism are LOW and reviewed first. FAIL also on a HIGH model finding with a cited line and confidence of at least 0.8 (cross-tenant read or write), and when any engine answer is unparseable. PASS when every handler was reviewed and nothing blocking was found. Without an AI engine the check is not executed (requires an AI engine).

Type

ai-assisted · engine chosen by the organisation · medium

1.0.4: `assess` mode cuts the candidate set to what the chosen ENGINE serves in ONE call (`ctx.ai.maxInputChars`, published by the engine per its catalogue budget; `ENGINE_CALL_MAX_CHARS` = 32 000 when an older sandbox does not publish it), instead of filling the call up to the TRANSPORT cap of the proxy (`spec.promptMaxChars`, unchanged at 120 000). On a 1 319-file checkout the old packing produced single prompts of 17 672 / 26 709 / 29 351 tokens and the platform GPU answered "CUDA out of memory": the check ended in `error`. Every call of the same run under ~24 000 characters was answered normally. The part aggregation of 1.0.1 is unchanged: a HIGH in any part is a FAIL, an unsatisfied part is a FAIL, undecided never passes. (1.0.3: requires an AI engine (spec.requiresEngine: true): the check needs judgement and is executed only when the organisation provides an engine; the core catalogue runs without one. (1.0.2: never analyses temporary files (*.tmp.*; spec.excludes follows AUDITOR_ANALYSIS_EXCLUDES). (1.0.1: never analyses test, spec, fixture and mock paths nor the auditor's own scripts (spec.excludes = AUDITOR_ANALYSIS_EXCLUDES); a fixture-looking secret (sk_test_, example, dummy) in real code is LOW, informative; every model call stays under the engine prompt cap (spec.promptMaxChars = AUDITOR_AI_PROMPT_MAX_CHARS): assess mode sends the candidate set in parts and aggregates the verdicts (a HIGH in any part is a FAIL, an unsatisfied part is a FAIL).)))

The full script is disclosed on request in a read-only viewer (never published on GitHub); the attestation binds to this exact hash.