The dashboard is correct, the export is not
A user sees only their company's records in the dashboard, then downloads a report containing another company's rows. The interface behaved as designed. The product failed because the company filter was a convention in the screen's query rather than an enforced boundary across every route to the data.
For a product serving multiple organisations, tenant identity belongs to the request's verified authority. A company identifier supplied in a URL or form is only a claim. The server must establish that the person may act for that company and that the requested operation is permitted within it. Hiding another company's navigation cannot do this work.
Put enforcement where omission becomes difficult
Shared databases can use database policies as part of the boundary. PostgreSQL supports row security, but table owners normally bypass it and privileged roles can bypass it too. The PostgreSQL documentation makes that limitation explicit. Testing a policy with a privileged application connection can create false confidence.
Choose the isolation model according to the product's operational needs. A shared schema, separate schemas or separate databases each create different maintenance and recovery work. None removes the need to validate authority at the application boundary. The important question is which mistakes the chosen design prevents and which still require checks.
Make the tenant context mandatory in data access paths that operate on customer records. Missing context should fail clearly rather than silently become an unrestricted query. Administrative access needs a separate, deliberate route with a reason and an audit record.
Background work must carry the boundary with it
An export job may run after the initiating request has ended. Its payload needs an unambiguous tenant reference and an explicit authority model. Decide whether it executes with the initiating user's current permissions or with a narrowly defined service permission. Do not leave that decision to whichever credential the worker happens to use.
Revalidate access before delivering the result. A person may have left the company while the report was being prepared. The file itself needs tenant-scoped storage and authorised download access; a correct database query does not help if the finished report is publicly retrievable.
Apply the same reasoning to scheduled notifications, search indexes and integration credentials. Each is another way to move information across the boundary. A background process should not gain the right to combine organisations merely because it runs without a browser session.
Caches and support tools are part of the product
A cache key based only on a record identifier can mix responses that depend on tenant or permission. Determine which identity and authorisation dimensions affect a result before deciding it is reusable. Include invalidation behaviour when membership or access changes, not only when the underlying record changes.
Support tools deserve particular attention. An impersonation feature, global search or downloadable diagnostic bundle can bypass restrictions that the customer interface handles carefully. Limit its purpose, record its use and avoid showing full sensitive payloads when a status or reference would answer the question.
The uncomfortable part is that convenient internal access often receives less scrutiny than public endpoints. A product cannot claim strong separation while treating its own operational shortcuts as outside the design. The boundary follows the data, including when the team is fixing a problem.
Try to cross the boundary this week
Create isolated test organisations with deliberately similar record names. Attempt to read and update across them through direct requests, exports, scheduled jobs and search. Use the actual application role rather than an administrator connection.
Then remove a member while their export is running and inspect the resulting file access. Repeat with cached responses and support workflows. Record the expected denial at each boundary. A tenant isolation review is successful when failures are blocked consistently, including the routes that never appear in the dashboard.