Agentic systems touch more than chat history. They can read repositories, meeting transcripts, credentials, issue trackers, cloud resources, and production telemetry. The isolation boundary has to cover the whole operating surface.
AWS makes an important distinction in its SaaS architecture guidance: tenant isolation is separate from authentication and authorization. A user can be authenticated, have a valid role, and still reach another tenant’s resources if tenant context is not enforced at every access boundary.
Silo, pool, and bridge
Isolation is not one deployment pattern. AWS describes several common models:
Single-tenant generally describes the silo end of this spectrum. It can simplify the story because coarse infrastructure boundaries reduce reliance on perfect application-level partitioning. It does not eliminate the need for identity, authorization, encryption, patching, monitoring, and secure operations.
Trace the complete boundary
For an AI engineering system, ask where tenant context is enforced across:
- Compute: agent runtimes, sandboxes, job queues, and background workers;
- Data: prompts, transcripts, embeddings, artifacts, logs, caches, backups, and evaluation sets;
- Identity: users, service accounts, roles, approval authority, and session scope;
- Secrets: repository tokens, model keys, cloud credentials, and connector permissions;
- Network: ingress, egress, private endpoints, and access to customer environments;
- Operations: support access, observability, incident tooling, exports, and deletion; and
- Providers: the model and external tools that receive tenant data.
A dedicated application instance with a shared logging sink or shared secret store may still create a crossing path. The system diagram should show data and authority flows, not only boxes labeled “tenant.”
Agents make least privilege urgent
An agent can chain individually valid actions into an outcome no single tool call reveals. Give each role only the tools and resource scope required for its responsibility. Separate read, write, deploy, and approval authority. Use short-lived credentials where practical, and bind every request to tenant and task context.
Do not rely on the agent prompt to preserve isolation. Prompts guide behavior; infrastructure and policy enforce boundaries.
Make isolation demonstrable
Customers should be able to understand what is dedicated, what is shared, where data is stored, which providers process it, and how access is logged. Internally, test negative cases: attempt cross-tenant identifiers, replay jobs under the wrong context, inspect cache and storage policies, and verify that support tooling cannot silently bypass the boundary.
Operational evidence should include provisioning records, resource ownership, policy versions, access logs, backup scope, deletion completion, and incident procedures. Isolation is strongest when it is observable and continuously checked—not inferred from the deployment diagram.
Questions to ask a vendor
- Which resources are dedicated to us, and which are shared?
- How is tenant context enforced at compute, storage, cache, queue, and logging layers?
- Can the system run in our cloud or network boundary?
- Which people and services can access our environment, and how is that access approved and recorded?
- Where do model providers and external connectors fit into the data flow?
- How are backups, exports, and deletion isolated?
- What tests prove that a cross-tenant request fails?
“Single-tenant” should start this conversation, not end it. The useful promise is a boundary that can be explained, tested, and evidenced across the complete system.