Definition
Tenant isolation
Tenant isolation is the guarantee that one customer's data in a shared, multi-tenant system can never be read or written by another — enforced at the data layer so a bug in application code can't leak across the boundary. It is the bedrock of SaaS trust, and in an AI platform it also means an agent's retrieval and context stay strictly within the workspace that invoked it.
Key takeaways
- Tenant isolation guarantees one customer's data can't be read or written by another in a shared system.
- The strongest form is enforced at the data layer (row-level security), so an application bug can't leak across tenants.
- AI raises the stakes — retrieval, agent context, and generated answers must stay scoped to the invoking tenant.
- Planoda enforces isolation with PostgreSQL RLS and scopes semantic retrieval and agent context to one workspace.
Multi-tenant systems put many customers' data in one database, which makes isolation a security property, not just a filter. The strongest form pushes the boundary down to the database itself — row-level security policies that scope every query to the current tenant — so even if an application query forgets a `WHERE`, the engine refuses to return another tenant's rows. Defense at the data layer survives mistakes in the code above it.
AI raises the stakes on isolation. Semantic retrieval, agent context, and generated answers all pull from stored data, so a leak there would surface one tenant's confidential content inside another's AI response. Sound design scopes the vector index, the retrieval, and the agent session to the tenant just as tightly as ordinary reads — isolation has to cover the AI path, not only the CRUD path.
Planoda enforces tenant isolation with PostgreSQL row-level security across its schema, and scopes semantic retrieval and agent context to a single workspace — so the AI features inherit the same boundary that protects ordinary data.
Related terms
- Multi-TenancyMulti-tenancy is an architecture where one running application and database serve many independent customers (tenants), with each tenant's data strictly isolated from the others. It lets a SaaS product share infrastructure for efficiency while guaranteeing that one workspace can never see another's data — a guarantee enforced in the data layer, not left to hope.
- Row-Level Security (RLS)Row-level security (RLS) is a database feature that restricts which rows a query can read or modify based on the current user or context. Instead of relying solely on application code to filter data, the database itself enforces access policies on every query — a strong defense for multi-tenant systems where one workspace's data must never leak to another.
- No-train guaranteeA no-train guarantee is a vendor's contractual commitment that your data — your issues, documents, and prompts — will never be used to train its or a third party's AI models. It is the baseline trust requirement for putting proprietary work into an AI platform: your content powers your features and nothing else, with no leakage into a shared model that competitors could query.
- Principle of Least PrivilegeThe principle of least privilege holds that every user, service, or process should be granted only the minimum permissions needed to do its job — and nothing more. By default-denying access and granting narrowly, you shrink the attack surface: a compromised account or buggy component can only reach what it was explicitly allowed, limiting the blast radius of any failure.
- Semantic SearchSemantic search finds results by meaning rather than exact keywords, using vector embeddings that place similar concepts near each other in mathematical space. A query for 'login broken' can surface an issue titled 'users can't authenticate' even with no shared words. It powers more relevant search and is the retrieval layer behind many AI features.