How do you enforce tenant isolation beyond database rows?

01Rows are only the first boundary

Most multi-tenant products start with a tenant column and a filter on every query. PostgreSQL row security policies make this stronger by enforcing the filter in the database itself, with a default deny when no policy matches. That is a good foundation. It is not the whole answer.

Real B2B platforms often have more than one kind of party looking at the same record. A wholesale company and its dealers, a franchisor and its locations, a platform and its resellers. In these products the question is rarely "may this tenant see this row?" It is "may this role, in this tenant, see this field of this row, for this purpose?"

AWS makes a related point in its SaaS architecture guidance: authentication and authorization are not isolation. A user can be signed in and authorized for a feature and still reach another tenant's data if isolation is not enforced separately, using tenant context on every access.

02Map the visibility rules before you write code

The most useful artifact is a visibility map: for each important entity, which roles see which fields. Draw it before building, and keep it in the repository.

A map like this exposes decisions early: who owns the customer, who can change price, who can refund. It also becomes the test plan.

03Enforce tenant isolation at every layer

Rows, fields and roles need enforcement in more places than the main database. The OWASP Multi Tenant Security Cheat Sheet is a good checklist. In practice we cover these layers:

1. 01

   Request context.

   Set the tenant on the server for every request, and treat any tenant ID sent by the client as a selector to verify, not a fact.

2. 02

   Database.

   Use row security for tenant scoping, and column level grants or separate views for field level rules.

3. 03

   API responses.

   Shape responses per role, so a field the role may not see is never serialized, not just hidden in the UI.

4. 04

   Caches and search indexes.

   Include the tenant in every cache key and index filter.

5. 05

   Files.

   Partition storage by tenant and authorize before issuing signed URLs.

6. 06

   Payments.

   Where each tenant uses its own payment account, keep the platform out of the money flow and store no card data.

7. 07

   Background jobs.

   Carry verified tenant context into queued messages and check it again in the worker.

8. 08

   Logs and exports.

   Include tenant context in audit events and restrict who can read them.

Test cross-tenant denial explicitly. For each role, write tests that try to read another tenant's data and another role's fields, and run them on every release.

04Plan for AI before you add it

AI features are a new path to the same data. A reporting agent, a support assistant or a search tool will read through whatever interface you give it. If that interface was written for internal admins, the agent will see what admins see.

Before adding AI to a multi-tenant product:

• Give the agent its own access path that applies the same tenant, role and field rules as the user it acts for.
• Scope retrieval to the current tenant before anything reaches the model.
• Keep embeddings and indexes per tenant, or filter them by tenant on every query.
• Log every agent read and write with tenant and user context.
• Add the agent to your cross-tenant denial tests.

We go deeper on this pattern in how to add AI agents to existing SaaS without rebuilding.

05Common isolation mistakes

When we review multi-tenant products, these are the gaps we find most often:

• Field rules enforced only in the UI, while the API returns the full record.
• Admin endpoints that skip tenant filters because they were written for internal staff.
• Reports and exports built on direct database queries that bypass the application rules.
• Shared cache keys for data that differs by tenant.
• Background jobs that run with a superuser connection, which row security does not constrain.
• Impersonation or support tools without an audit trail.

Each one is easy to miss because the product looks correct from the screens. The fix is to test from the outside: call the API as each role in each tenant and check exactly which fields come back. Repeat those tests whenever a new endpoint, report or integration is added, and treat a failed test as a release blocker.

It also helps to name an owner for the visibility map. When the business adds a new party, such as a reseller or a partner, the map is updated first, and the code follows.

06What we see in production

For a premium custom print company with a wholesale dealer network, we replaced the dealer side of a 15 year old legacy system with a multi-tenant platform where each dealer runs a branded storefront with its own pricing, promotions and payment account, while every order flows back to the company for production and shipping.

Isolation had to work per field and per role, not just per tenant. The same customer is fully visible to the dealer and only partly visible to the central company: central admins see shipping details, not the full profile. The catalog stays central, and dealers control only visibility, pricing and descriptions. Dealers collect payment in their own accounts, so the platform holds no funds and stores no card data, which keeps it out of card data scope.

We added tenant filtering across backend and frontend, role based access for super admin, dealer admin, dealer staff and customer, and recommended snapshotting variant data into each order so later price changes never alter past orders. The platform runs on the client's own AWS account.

There was no AI in the delivered scope, but the scope document asked for an architecture ready for future agent based features such as intelligent reporting and AI customer support. Any such agent will have to respect the same field and role boundaries, which is far easier because they already exist in one place.

Frequently asked questions