TenantTrace — tenant isolation audit

[{"id":"fcd2396a-de3b-4c9a-87fc-ac5b52f49fcb","name":"tt-canary-…ac95f950 customer 0","email":"c0@example.invalid","tenant_id":"9a8f7557-6de7-4cbd-8fc8-15eece3b82a7"},{"id":"d98876cc-2d4b-4f03-9d45-cef8c2a22c85","name":"tt-canary-…ac95f950 customer 1","email":"c1@example.invalid","tenant_id":"9a8f7557-6de7-4cbd-8fc8-15eece3b82a7"}]

`GET /api/customers` takes the tenant from the request instead of from the authenticated session. Changing one parameter switches tenants, which makes every other isolation control on this endpoint irrelevant.

The tenant must be derived from the credential and from nowhere else:

# before — the caller chooses
def list_items(tenant_id: str | None = None, ctx = Depends(current)):
    scope = tenant_id or ctx.tenant_id

# after — the credential chooses
def list_items(ctx = Depends(current)):
    scope = ctx.tenant_id

If an internal caller genuinely needs to select a tenant, that is a separate, explicitly authorised admin endpoint — and it belongs in `cross_tenant_allowlist`, not in the tenant-facing route.

[{"id":"505ead99-cc85-497c-996e-02e55921f7db","title":"Document 0","body":"tt-canary-…c2847275 document body 0","tenant_id":"c32b4cdc-01fc-4b7d-91c2-66dac3173cc7"},{"id":"abcda6fb-b0e9-4d46-8c5e-0ef7e7ccc2db","title":"Document 1","body":"tt-canary-…c2847275 document body 1","tenant_id":"c32b4cdc-01fc-4b7d-91c2-66dac3173cc7"},{"id":"dc2b8a4d-e4aa-4e45-8c4e-dece5aa50e41","title":"Document 0","body":"tt-canary-…ac95f950 document body 0","tenant_id":"9a8f7557-6de7-4cbd-8fc… [189 more characters]

`GET /api/documents` lists rows belonging to every tenant. A collection query without a tenant predicate leaks in bulk, which is strictly worse than a single-object leak: the caller does not even need to guess an id.

# before
rows = session.scalars(select(Document)).all()

# after
rows = session.scalars(
    select(Document).where(Document.tenant_id == ctx.tenant_id)
).all()

Add a regression test that seeds two tenants and asserts the list length for one of them — a single-tenant test suite cannot catch this class of bug.

{"id":"7e17cdaa-349e-4bd1-b08a-b34f655c8bb1","title":"tt-canary-…ac95f950 invoice 0","amount":100,"tenant_id":"9a8f7557-6de7-4cbd-8fc8-15eece3b82a7","created_at":"2026-07-27T14:21:16.972898"}

`GET /api/invoices/{invoice_id}` returns an object owned by another tenant. The lookup resolves the identifier without constraining it to the caller's tenant, so any tenant holding a valid id can read the record.

Fix it at the data-access boundary, not in the route handler:

# before — the id is trusted on its own
obj = session.get(Invoice, obj_id)

# after — identity is (tenant, id), never id alone
obj = session.scalars(
    select(Invoice)
    .where(Invoice.id == obj_id)
    .where(Invoice.tenant_id == ctx.tenant_id)
).one_or_none()

Better still, make the unsafe call unavailable: put the tenant predicate in a repository method or a SQLAlchemy `with_loader_criteria` global scope so a future route cannot forget it. Return 404 rather than 403 for another tenant's object so the response does not confirm that the id exists.

{"id":"f0fe6e5c-21c7-4707-82d7-95b4b52f5d3b","title":"tt-canary-…c2847275 (created by TenantTrace, safe to delete)","amount":1,"tenant_id":"9a8f7557-6de7-4cbd-8fc8-15eece3b82a7","created_at":"2026-07-27T14:21:17.366120Z"}

`POST /api/invoices` accepts a client-supplied `tenant_id` and writes the record into another tenant. Mass assignment binds the whole request body onto the model, so any column the model exposes is attacker-controlled.

Bind an explicit input schema that simply does not contain the ownership column, and set it from the authenticated context:

class $modelCreate(BaseModel):
    model_config = ConfigDict(extra='forbid')  # reject unknown keys
    title: str
    amount: int
    # NOTE: no tenant_id here — ownership is never client input

obj = Invoice(**payload.model_dump(), tenant_id=ctx.tenant_id)

Apply the same rule to updates: an update must never be able to move a record between tenants.