Multi-tenant isolation: one platform, many customers
The trust chapters so far protected a platform from hostile input. This one protects tenants from each other. The moment your agent platform serves more than one customer, team, or end user from shared infrastructure, a new failure class appears: one tenant seeing another's data, spending another's budget, or starving another's throughput. Multi-tenancy is where every control the book has built (budgets, state, sandboxes, quotas, IAM) grows a per-tenant dimension, and getting it wrong is the difference between a bug and a breach that ends up in a regulator's inbox.
Four isolation questions
A multi-tenant platform must answer four questions, and they map onto four things the book already built. Naming them this way turns a scary topic into a checklist:
- Data: can tenant A read tenant B's state or memory?
- Budget: can tenant A spend tenant B's tokens or dollars?
- Compute: can tenant A's code touch tenant B's execution?
- Throughput: can tenant A's load starve tenant B's requests?
Each has an answer from an earlier chapter, now given a tenant axis.
Data isolation
The state store's single-table design already
carries the answer: put the tenant in the partition key. A run's key
becomes tenant#acme/run#42, and every query is scoped to a tenant
prefix, so a query for Acme's runs structurally cannot return
Globex's, because it queries a different partition space. The same
holds for memory: namespace every memory
by tenant, so retrieval for Acme searches only Acme's vectors. And it
composes with IAM: the session policy for a
task includes the tenant in its resource scope
(table/agent-state/tenant#acme/*), so even a compromised worker's
credentials cannot address another tenant's partition. Data isolation
is thus enforced twice, by key design and by IAM, which is the right
number of times for something this consequential.
The stakes rise when tenants are external customers rather than internal teams. Internal multi-tenancy tolerates a shared-fate model (a bug might leak team A's data to team B, embarrassing but recoverable); external multi-tenancy does not, and may demand harder boundaries: per-tenant encryption keys, separate tables or accounts for the largest customers, and an auditable guarantee that the isolation holds. Decide early which regime you are in, because retrofitting hard isolation onto a soft-multi-tenant design is close to a rewrite.
Budget and throughput isolation
The budget ledger and the quota governor both gain a tenant dimension, and both guard against the same villain: the noisy neighbor, one tenant whose load degrades everyone else.
For budget, the ledger tracks spend per tenant against a per-tenant cap, and admission control checks the tenant's remaining budget, not just the run's. A tenant that exhausts its allocation gets its runs parked, and, crucially, other tenants are unaffected, because the cap was theirs alone. Without per-tenant budgets, a single customer's runaway fleet can spend the shared pool and the invoice lands on you.
For throughput, recall the bystander lesson: the whole account shares one model quota, so one tenant slamming it produces 429s for everyone. The governor must therefore allocate quota per tenant, so Acme's burst draws from Acme's share and leaves Globex's intact, plus fairness so a heavy tenant cannot monopolize the pool even within the account limit, and admission control that queues a tenant's excess rather than letting it flood. This is the swarm scheduler's fairness dimension that Chapter 23 deferred; multi-tenancy is where it becomes mandatory rather than nice.
Compute isolation
The sandbox plane already answered the compute question at the strongest level: a microVM per execution means one tenant's agent code runs behind a hardware boundary from every other's, with no shared kernel to escape through. Per-session microVM isolation, which AgentCore Runtime provides by default and the DIY service builds, is tenant compute isolation when sessions are per-tenant. The one thing to verify is that the mapping is actually one-to-one: a sandbox reused across tenants (for speed) reintroduces exactly the cross-tenant leak the microVM was preventing, which is why the sandbox service destroys the microVM after each use. Freshness-by-destruction and tenant isolation are the same property seen from two angles.
The multi-tenancy checklist
Assembling the four answers into a review artifact, because multi-tenancy failures are quiet until they are catastrophic:
| Question | Enforced by | Verify |
|---|---|---|
| Data isolation | Tenant in the partition key + tenant in the IAM resource scope | A query for tenant A cannot address tenant B's partition, twice over |
| Budget isolation | Per-tenant cap in the ledger; admission checks it | Tenant A's exhaustion parks A's runs and touches no one else |
| Throughput isolation | Per-tenant quota share, fairness, admission | Tenant A's burst degrades A's latency, not B's |
| Compute isolation | MicroVM per execution, sessions mapped one tenant to one sandbox, destroyed after use | No sandbox is ever reused across tenants |
Run this checklist before onboarding the second tenant, not after an incident with the twentieth. Every row is a control the book already built; multi-tenancy is not new machinery, it is the discipline of giving each existing control a tenant key and verifying the boundary holds.
Don't be confused: multi-tenant vs multi-agent. They sound alike and are orthogonal. Multi-agent (Part 6) is many agents cooperating on one goal, inside one trust domain, sharing a budget and a ledger on purpose. Multi-tenant is many customers who must be kept apart, each with their own budget, data, and isolation, cooperating on nothing. A single tenant can run a five-hundred-agent swarm; a platform can serve a thousand tenants each running one agent; and a big platform is both at once, a swarm per tenant, which is exactly why the budget, quota, and data controls all need a tenant key even though the swarm mechanics do not care about tenancy at all.
Part 8 is complete: the agent as a scoped principal, injection bounded by the trifecta, consequential actions gated by humans without fatigue, and tenants isolated across data, budget, compute, and throughput. The platform is now defensible, which is a precondition for the operations that make it runnable.
👉 Next, per the map: Part 9 turns the defensible platform into an operable one, observability, evals, cost, and the on-call runbook, then the protocols and capstones that finish the book.