tenant-isolationlisted

# Tenant Isolation for Agentic Products Tenant isolation is a **trust-boundary decision made once, at the data plane** — not a `WHERE tenant_id = ?` you sprinkle in later. Retrofitting it is the migration nobody budgets for, and the first cross-tenant leak is often a churn-and-lawsuit event, not a bug ticket. Agentic products raise the stakes. A normal SaaS app only does what its code says. **An agent is a confused deputy**: if isolation lives in the prompt ("only answer about the current customer"), the model will eventually retrieve, blend, summarize, or cache another tenant's data — via prompt injection, an ambiguous query, or a tool it was talked into calling with the wrong id. **Isolation must be enforced in code, below the model, fail-closed.** ## First question: do you even need multi-tenancy? | Situation | Answer | |---|---| | One deployment per customer (their VPC / their DB) | **Silo by deployment** — strongest isolation, no shared data plane. Skip the rest if true. | | Shared app, a handful of large enterprise tenants | **Silo by schema/DB** per tenant | | Shared app, many tenants (SMB SaaS) | **Pooled + row-level security** is the default | | Internal tool, single org | You don't have tenants — don't build for them | Don't build pooled multi-tenancy speculatively. But if tenants share *any* row, index, cache, or memory store, you need every control below — there is no "lightweight" cross-tenant isolation. ## The three isolation models | Model | How | Isolat