Tenant Isolation for AI Apps: Shared Pool vs. Per-Tenant Boundary

Every multi-tenant system makes one foundational choice: how much infrastructure do tenants share? Tenant isolation for AI workloads turns that choice from an economics question into a security one. When the code running next to your customers' data was written by a model and reviewed by nobody, "how close is this app to the neighbor's records?" stops being an architecture detail and becomes the whole risk.

The choice is a spectrum, and the industry has standard names for the ends of it.

The isolation spectrum: pool vs. silo#

AWS describes two anchor models in its SaaS tenant isolation guidance. In the pool model, "tenants share some or all of their underlying infrastructure": the same compute, often the same database tables, indexed by a tenant identifier. Tenants 1 through N run side by side. It is density-first, so resources scale in proportion to actual load and you pay for what everyone uses collectively rather than provisioning idle capacity per customer. The tradeoff is that you "can't lean on the typical networking and IAM constructs to create boundaries between tenants." Isolation lives in application logic, essentially a WHERE tenant_id = ? clause, and the infrastructure enforces nothing on its own.

In the silo model, each tenant runs "a fully siloed stack of resources," wrapped in a construct that becomes "our boundary for isolation." Every customer gets their own boundary. It costs more and it is more work to operate, and the separation is structural rather than a line of code that has to be right every single time.

A crucial point AWS makes: isolation is a different control from authentication. "The fact that a tenant user is authenticated does not mean that your system has achieved isolation." A perfectly authenticated, authorized request can still reach another tenant's data if the isolation logic has a gap. Login answers who are you. Isolation answers which records may this request touch.

Tenant isolation for AI: why the stakes rise#

In a pooled model, the logical boundary is only as good as the code enforcing it. That is a defensible bet when a human wrote and reviewed every query. It becomes a very different bet when an agent generates the query at machine speed and ships it unreviewed.

Two failure modes get sharply worse. First, a hallucinated or malformed query: a model that drops the tenant predicate is now issuing a broad read against a table holding every tenant's rows. In a silo there is nothing else in the table to reach. In a pool, the neighbor's data is one missing clause away. Second, prompt injection, which OWASP's LLM Top 10 ranks as the number-one risk. Untrusted input "alters the LLM's behavior in unintended ways" and can lead to "unauthorized access" and "executing arbitrary commands in connected systems." An injected instruction that runs an unscoped query lands wherever the agent can reach, which in a pool is the shared store.

Blast radius and data residency#

Two properties decide how bad a failure gets. Blast radius is the first. In a silo, AWS notes, "any failures that occur within a given tenant's environment will likely be constrained to that environment." In a pool, "an outage will likely impact all the tenants." Add the noisy-neighbor problem, where one tenant's heavy load degrades everyone else's, and a single runaway AI job can starve or stall the whole shared plane rather than just its own slice.

Data residency is the second. Regulated customers often need their data confined to a specific jurisdiction or account. A silo makes that a placement decision. A pool, where records interleave in shared tables, makes it a much harder promise to prove, which is why AWS flags compliance "pushback" as a standard cost of pooling. When an auditor asks where a customer's data lives and what touched it, "it's all in one table, separated logically" is a hard story to defend for unreviewed AI workloads.

Property	Pool (shared)	Silo (per-tenant)
Cost & density	High efficiency, shared scaling	Lower efficiency, idle capacity
Isolation enforced by	Application logic (tenant ID)	Infrastructure boundary
Blast radius	All tenants	One tenant
Noisy neighbor	Present	Eliminated
Data residency & audit	Harder to prove	Straightforward

Where pooling still makes sense#

None of this makes pooled architecture a mistake. It is the right default for a huge range of software: cheaper, easier to operate, and a well-reviewed logical boundary holds up fine for a stateless API or an internal dashboard. The economics that make SaaS work are largely pooled economics.

The argument here is narrower. AI-generated software running against real, sensitive data is the one workload where the pooled bet inverts. Pooling asks you to trust correct, reviewed isolation logic on every path, and AI code generation is what removes that review. Security teams have noticed and increasingly draw a hard line: unreviewed AI code gets a real boundary, or it stays away from production data. The runtime the code executes inside becomes the control, because the code itself can no longer be the guarantee.