Tenant isolation testing for multi-tenant SaaS
In multi-tenant SaaS, tenant isolation is the promise that one customer or organization can never see or touch another's data. Sintropyc tests that promise directly: it stands up two tenants and tries to cross the boundary — through IDs, JWT claims, sub-domains and shared storage — and proves any crossing with real data.
What tenant isolation means
Most SaaS apps put every customer in the same database and separate them with an org_id (or tenant_id) on each row and a check on each request. Isolation holds only if every path enforces that check. Miss one — a report export, a webhook, an admin endpoint, a cached response — and one tenant can read another. A single crossing is a reportable breach and, for SOC 2 or ISO 27001, a control failure.
Where isolation breaks
- Object references that check authentication but not tenant — an object-level authz gap scoped to org
- JWT / session claims — a
tenant_idthe client can change, or one the server never re-verifies - Sub-domain or path routing —
acme.app.comdata reachable fromglobex.app.com - Shared storage, caches and search indexes that forget the tenant filter
- Background jobs and exports that run with a wider scope than the user
How Sintropyc tests it
Sintropyc is an autonomous AI penetration testing agent. It signs in as real users across different roles, drives your product the way a customer would, and proves every finding with a working exploit — never a scanner guess. Each finding is checked by a human before it reaches you, comes with the exact fix, and is attacked again after you ship it to confirm it held.
Sintropyc uses two real tenants and, from tenant A's session, attempts to reach tenant B across the whole surface — API objects, files, realtime channels, exports and admin paths. It reports a finding only when it holds tenant B's data in tenant A's hands, with the exact request as proof.
Why this sells your security to enterprise buyers
When a larger customer asks "can another tenant see our data?", "we think so" isn't an answer. A proof-backed isolation test — every crossing attempted, every one shown to fail — is exactly the evidence that unblocks the deal.
Common questions
We use Supabase/Postgres RLS for isolation — is that enough?
RLS is a strong foundation, but isolation still fails through paths RLS doesn't cover: edge functions, storage, caches, exports and mis-set policies. See our Supabase security audit. Sintropyc verifies the whole boundary, not just the database.
Do you need two of our tenants?
Two test tenants (yours or ones we create with your go-ahead) give the cleanest proof. We never use one real customer's data to test against another's.
Is it safe to run on production?
Read-only by default and demonstrated with the smallest safe effect. For write paths we prefer a staging mirror; anything risky needs explicit sign-off.