# Measure isolation failures outside the main API

Include jobs, exports, caches and support tools in the evidence. A clean set of controller tests does not establish isolation across the application.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Inventory the protected paths

List operations that read, change or export tenant data. Include asynchronous workers, search indexing, file downloads, bulk imports and administrative actions.

For each path, record how tenant identity is established, where access is checked and which runtime identity reaches storage. Mark untested paths explicitly.

Coverage is a useful measure, but it is not proof by itself. Ten tests against the same helper may leave a direct SQL job completely unexamined.

## Test both disclosure and mutation

Use paired tenants with recognisable synthetic records. Assert that responses contain only permitted data and that writes affect only the intended tenant.

Inspect side effects such as exported files, notifications and cached results. A denied final response can coexist with an incorrect background mutation.

Record failures by boundary: untrusted tenant selection, unscoped lookup, connection-context leakage, cache reuse or administrative bypass. The categories help engineering fix the mechanism rather than add another isolated route check.

## Include runtime configuration evidence

Test the actual application database role and relevant storage permissions. Row policies can behave differently for owners or privileged roles, so a restricted test identity may not represent production.

Exercise concurrency, connection reuse and failure cleanup. Tenant context bugs often appear only when one execution follows another on shared infrastructure.

Keep configuration versions with the results. A permission or pool change can alter isolation without changing the route code covered by unit tests.

## Treat failures according to consequence

Cross-tenant disclosure or mutation should not be averaged away by successful ordinary requests. Report each observed failure and the affected path, even in a large passing suite.

Track remediation and regression coverage, with a separate view for remaining untested or deliberately privileged paths. Do not present zero observed failures as a universal guarantee beyond the cases and configuration examined.

Acceptance should establish a traceable boundary for every supported data path and show that important negative cases were exercised. The useful question is where isolation is enforced and verified, not simply how many API tests are green.

## Sources

- [PostgreSQL: row security policies](https://www.postgresql.org/docs/17/ddl-rowsecurity.html)
- [OWASP: multitenant security](https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html)