When many customers share one Bedrock model, the model gives you no isolation and was never going to. It is a stateless function: same input, same behavior, no memory of who called it. Every boundary between tenants has to be built in the layers around the model, not expected from it. Teams get this backwards, assume the managed service handles separation, and ship an app where one tenant's data, cost, and load bleed into another's. The shared model is fine. The shared everything-else is the problem.

The reassuring part is that the model being stateless is also what makes multi-tenancy tractable. There is no per-tenant state inside the model to leak, because there is no state at all. Isolation reduces to three concrete boundaries you already know how to build: what data a tenant's request can reach, how much of the shared capacity it can consume, and which identity it runs as.

Data isolation: scope the retrieval, not the model

The real leak risk in a RAG or agent app is not the weights, it is the context you put in front of them. If tenant A's question retrieves tenant B's documents, you have a data breach dressed up as a helpful answer. So the retrieval layer is where tenant separation lives.

Two workable shapes, depending on how strict the boundary must be:

  • Knowledge Base per tenant. The hard boundary. Each tenant gets its own Bedrock Knowledge Base, so a query can only ever retrieve from that tenant's corpus. Cleanest to reason about, more moving parts to manage as tenant count grows.
  • Shared store, tenant-filtered. One vector store with a mandatory tenant-ID filter on every query, so results are scoped by metadata. Cheaper to operate, but the filter is now load-bearing security. It must be applied server-side from an authenticated identity, never from a value the client can set.

The failure to avoid is filtering on a tenant ID that arrived in the request body. If the client can name its own tenant, the client can name someone else's. Derive the tenant from the authenticated principal and apply the scope where the client cannot reach it.

The noisy neighbor: a shared quota is a shared failure

Bedrock throttles on tokens per minute at the account and model level. That number is shared across every tenant hitting that model in your account. So one tenant running a heavy batch job spends the shared token budget, and every other tenant starts collecting throttling errors for load they did not generate. The model is isolated logically and coupled operationally.

Isolation here means metering and capping per tenant before the shared ceiling does it for you:

  • Per-tenant token budgets. Track tokens consumed per tenant per window and reject or queue a tenant that blows its own allocation, so its spike cannot eat the shared pool.
  • Fair queuing. A bounded per-tenant worker pool in front of the model turns one tenant's burst into that tenant's slowdown, not everyone's outage.
  • Priority tiers. If tenants pay for different service levels, enforce it in admission control. A free-tier batch should not be able to starve a paying tenant's interactive traffic.

Identity: the tenant boundary should reach the tools

Isolation cannot stop at retrieval. The moment an agent calls a tool, reads from a database, or writes to storage, the tenant boundary has to travel with the request. That means the request runs under an identity scoped to the tenant, so even if the model is talked into requesting the wrong data, the credentials behind the tool cannot fetch it. The model layer trusts nothing; the IAM layer enforces everything. This is least privilege applied per tenant, and it is what keeps a prompt-injection attempt from turning into a cross-tenant read.

The takeaway

A shared model is not a shared-everything app. The model is stateless, so it provides no isolation and needs none of its own protected. Your job is the three boundaries around it: scope retrieval so a tenant only sees its own data, meter and cap capacity so no tenant starves the others on the shared token quota, and carry a per-tenant identity all the way to the tools so a scoped credential is the last line when the prompt layer is fooled. Build those three and one model serves many customers safely. Skip any one and the model will happily serve the wrong customer's data to the wrong customer.

Read this next

For the platform and multi-account isolation side of the same problem, the cloud field notes live at ercan.cloud, and the hub is at ercanermis.com.