A customer changes an invoice number in a download request and receives another company’s PDF. The application has a login page, its dashboard filters records correctly, and the demonstration accounts looked separate. None of that prevented the disclosure.
This is a hypothetical example, but it illustrates a practical problem with AI-built B2B SaaS: an interface can suggest isolation that the rest of the system does not enforce. Before adding a first customer, the team needs evidence that tenant boundaries hold across the whole application.
Define the tenant model, including exceptions
A tenant is not always the same as a user or an email domain. One customer organization may have several business units. A consultant may belong to multiple organizations. An employee may need restricted access within one tenant. Support staff may require a separate, auditable access path.
Write down these relationships before relying on a generated data model. Decide who can create an organization, invite a member, change membership, and select an active organization. Specify what should happen to existing sessions when access is removed.
Tenant context must come from a trusted, verified relationship. A request containing an organization identifier is not proof that the caller belongs to that organization. The server must resolve the authenticated identity, check membership, and apply the appropriate permissions.
Choose an isolation model deliberately
Applications can separate tenants using dedicated environments, separate databases or schemas, shared tables with enforced controls, or combinations of these. Each option has tradeoffs in operation, cost, customization, and the consequences of a mistake.
A shared table is not automatically unsafe, and a dedicated database is not automatically sufficient. A shared implementation needs consistent enforcement on every relevant query. A dedicated implementation can still leak information through shared files, routing, support tools, or incorrectly selected connections.
The architecture should explain why its model fits the customers and what prevents a developer from bypassing it accidentally. Database-level controls can provide another enforcement layer where supported, but they also need correct configuration and testing. A policy name in a migration is not evidence that the policy protects every path.
Follow the data beyond database queries
Begin with a single sensitive record and follow every place it can appear. The invoice example may involve a database row, a generated PDF, a storage object, a notification, a search result, and an export. Every representation needs the right boundary.
Download links deserve particular care. If authorization happens only when a page renders, a subsequently reused link may remain available after membership changes. Signed links may be appropriate, but their scope, lifetime, and exposure must match the sensitivity of the resource.
Caches and search indexes can fail less visibly. A cache key based only on a report name may reuse another tenant’s result. A search index may return document snippets from outside the caller’s organization even if opening the document is later blocked. Check metadata and counts as well as complete records.
Background jobs need tenant context too. A queued report should not rely on whichever organization a worker processed most recently. Retries, scheduled exports, and administrative repair tools must preserve the same isolation rules as interactive requests.
Test attempts to cross the boundary
Create at least two test tenants with distinct records and users. Then deliberately submit identifiers from one tenant while authenticated as a member of the other. Exercise reads, updates, deletes, exports, uploads, search, and notifications. Testing only the dashboard misses much of the application.
Include users with different roles, users whose membership has been revoked, and users who switch between organizations. Verify both the response and the resulting data. A forbidden response is not enough if the mutation already happened before authorization failed.
For asynchronous work, inspect the generated result rather than merely checking that the job completed. Run repeated and concurrent requests where shared state might matter. Security assertions should become regression tests so the next generated feature does not silently remove the boundary.
The OWASP Multi-Tenant Security Cheat Sheet provides a practical reference for reviewing these cross-cutting concerns. It complements, rather than replaces, a review of the application’s actual architecture.
Treat support and recovery as tenant-aware operations
Ask how the team will investigate an incident without exposing unrelated customers’ data. Access to logs, administrative screens, and production exports should be controlled and auditable. Broad support access is a design decision with consequences, not an inevitable convenience.
Backups create another question: can one customer’s records be restored or deleted without damaging another customer’s state? The answer may depend on the storage model and contractual obligations. It should not be discovered for the first time after a customer requests recovery.
AI can assist with implementation and generate useful adversarial test cases. Engineers still need to choose the isolation model, verify its enforcement, and own the evidence. For B2B SaaS, tenant separation is part of the product’s basic promise—not a feature to add after the first sale.
Related reading
- Vibe Coding Architecture: Decisions to Make Before the Next Prompt
- Vibe coding: platforms, B2B risks, and delivery choices
Put the right guardrails in place
SaM Solutions can assess your project, review its architecture, and help decide where AI-assisted development fits.