Tenant isolation in an AI SaaS product means one customer cannot retrieve another customer's documents, reuse their conversation history or perform actions with their credentials. A login screen does not establish that boundary, and a prompt asking the model to respect it is not an access-control mechanism.
Adding AI expands the places where customer data travels. Retrieval indexes, background workers, caches, conversation memory and tool integrations all need the same account boundaries as the main application. This guide maps those paths and describes the checks a team should run before inviting paying customers.
Start with a trusted tenant context
Determine the active tenant from an authenticated identity and verified membership. If a request selects a workspace, the server must check that the person can access it. A workspace identifier supplied in a browser request is a selection, not proof of permission.
Carry that validated context into each downstream operation. A background task needs the tenant identifier, the intended operation and enough authorisation context to apply the right policy. Recheck permissions where the operation requires current membership or authority, especially when work is delayed.
AWS distinguishes tenant isolation from general authentication. A user can be logged in correctly while the application still allows access to another customer's resources.
Map every boundary an AI request crosses
| Component | Common failure | Boundary to enforce |
|---|---|---|
| Document upload | An object is stored without reliable ownership | Tenant and resource permissions on storage and metadata |
| Retrieval | Search returns chunks from another workspace | Authorised scope before results reach the model |
| Conversation history | A supplied conversation ID loads another customer's messages | Tenant and user access checks on every history lookup |
| Cache | A repeated prompt returns an answer generated from someone else's documents | Keys that include the relevant tenant and permission context |
| Background jobs | A worker runs with global access and a missing tenant filter | Explicit account context and constrained data access |
| Tools and integrations | The agent uses the wrong customer's CRM connection | Server-side credential selection and operation-level permission checks |
The table is a review checklist, not a guarantee of security. The appropriate controls depend on the data, tenancy model and actions your service supports.
Apply retrieval permissions before generation
For an illustrative knowledge-assistant SaaS, two companies may upload documents containing similar project names. If retrieval searches a shared collection without enforced scope, the model can receive the wrong company's text even when the final answer looks plausible. This is a hypothetical example, not a reported client incident.
Apply tenant and resource permissions during retrieval, before any chunks enter the model context. Filtering the final answer is too late: the untrusted context may already have influenced the response or reached another service.
A shared index can be viable if its access controls are enforced consistently and tested. Separate collections or infrastructure can create additional boundaries but also introduce provisioning and operational work. Decide based on the isolation requirements rather than assuming that a particular storage layout solves every access problem.
AWS's guidance on multi-tenant agents applies the same principle to agent knowledge and tools: access policies need to follow the tenant context through the resources the agent uses.
Review memory and caching separately
A conversation identifier should never grant access on its own. Check its ownership and the caller's authority when loading messages, attachments or summaries. Include generated summaries in retention and deletion plans; deleting the original chat while retaining its summary may leave sensitive material available.
Be cautious with shared semantic caches. Two similar prompts do not imply that the users have access to the same documents. If an answer depends on private context, cache scoping must reflect the tenant and relevant permission state. Invalidation matters when a person loses access or a document is replaced.
Keep operational logs useful without turning them into another unrestricted document store. Decide what is recorded, who can inspect it and how long it remains. A support dashboard that crosses tenant boundaries deserves the same review as the customer-facing API.
Constrain tools independently of model instructions
If an assistant can search a CRM, send a message or update a record, the tool handler must validate the action using trusted account context. Do not let the model choose an arbitrary tenant identifier or retrieve global credentials from a tool argument.
Select the customer's integration connection server-side, constrain the operation to authorised resources and validate its inputs. Require appropriate confirmation for consequential actions according to the product's rules. A confirmation does not replace the permission check: the person approving the action must also have authority to perform it.
Prompt injection can arrive through retrieved documents or tool results. Treat that content as input rather than authority. The model's instructions should not be the only barrier between a malicious document and another customer's data.
Background work needs explicit ownership
Uploads often trigger parsing, embedding and indexing jobs. Preserve the tenant and resource identity through each step. Check that output objects and index entries retain the same ownership when a job retries or a worker restarts.
Handle deletion and membership changes deliberately. An old job should not silently recreate a deleted document or publish content into a workspace after the underlying operation has been cancelled. Use resource versions or other explicit state checks where needed.
Apply account-level capacity controls too. One customer's large indexing run should not consume all worker capacity or an unlimited model budget. Our guide to AI SaaS metering and spending limits covers how admission and usage accounting fit together.
Build an isolation test matrix
Create two test tenants with deliberately similar data, then attempt to cross their boundaries. Include members, administrators and a user whose access has been revoked.
- Swap document, conversation and download identifiers between tenants.
- Search for an exact phrase present only in the other tenant's documents.
- Repeat the same prompt in both tenants and inspect cache behaviour.
- Queue work, change access or delete the resource, then let the worker continue.
- Attempt a tool call naming another tenant's record or integration connection.
- Retry ingestion and verify that no output loses its original ownership.
- Check support and administrative paths, not only normal customer endpoints.
Inspect the retrieved context and tool requests as well as the final answer. A response can hide a retrieval failure by omitting the leaked material. Negative tests should establish that unauthorised content was never supplied to generation or acted on.
Use database controls as one part of the boundary
Where the stack supports it, database policies can help enforce access beyond individual API handlers. They do not automatically protect external vector stores, object storage or privileged background services. Trace each route around the database as part of the review.
In our Supabase workspace and role-layer case study, database Row Level Security and tests were part of the implementation. That case describes a specific access layer; adding AI retrieval or tools would require reviewing those additional paths too.
For the broader product architecture, see our multi-tenant SaaS development guide.
Frequently asked questions
Is a separate database required for every customer?
Not universally. Shared and dedicated designs have different trade-offs. Whichever model you use, enforce and test the tenant boundary at every access path.
Can a system prompt prevent cross-customer data leaks?
No. Enforce permissions in the services and data layers supplying context and executing tools. Prompts can guide behaviour but should not grant access.
Does an AI feature need a separate security review?
Review the new data and action paths it introduces, even if the main application already passed a review. Retrieval, memory, integrations and background jobs can change the access model.
Review the paths before adding more capabilities
List the accounts, resources and operations involved before expanding an assistant's access. Use a focused discovery phase to resolve architectural uncertainty, then agree concrete isolation tests as release criteria. EmphaSoft builds SaaS platforms and AI features. To discuss an existing architecture or a planned release, tell us about your product.