Multi-Tenant Isolation for AI Agents: Where Each Tenant's Data and Compute Run

A security review for an AI agent platform usually reaches the same set of questions within the first hour. Where does the vector index built from our contracts live? Which region is it in? Whose embeddings share that search service with ours? Which machines execute our agents' tool calls, and what is left on them afterwards? If we leave, what gets torn down and who can prove it?

Many platforms answer with database-level isolation, and that answer covers only part of the question. Multi-tenant isolation for AI agents has to extend to every place an agent stores or processes tenant data: files, embeddings, agent memory, compute workers, environments, keys and the event stream that records what happened. This article covers that layer of AI agent infrastructure. Query-level isolation inside the database, and why it must be enforced at the data layer, is covered in our article on runtime access control for AI agents.

Why AI agents widen the multi-tenant isolation problem

A conventional SaaS application keeps most tenant data in rows and files. An agent platform creates several more places where one tenant's information sits, and each of them can be shared or dedicated:

• Files and documents uploaded for agents to work from.

• Embeddings and vector indexes built from those documents for semantic search. They are derived from the source material, so a security team classifies them at the same level as the documents themselves.

• Agent memory: the insights, entities and decisions an agent keeps between runs.

• Compute workers that execute tool calls, hold intermediate results and call external APIs during a run.

• Environments where agents are built, tested and run in production.

• Keys, credentials and network paths used to reach the tenant's own systems.

• Event and audit streams that record every action.

Isolation at the database alone leaves the other six to convention. The multi-tenant collapse described in our contextual governance article happens in exactly these gaps: an agent that can traverse integrations can, if misconfigured, traverse tenant boundaries wherever the boundary depends on application code alone.

Silo, pool and bridge: the three tenancy models

The AWS Well-Architected SaaS Lens gives the clearest vocabulary for multi-tenant isolation. In its terms, the silo model fully isolates each tenant's storage, while the pool model shares storage constructs across all tenants. The bridge model mixes the two, for example by sharing a web tier while giving each tenant its own application tier and storage.

Source: AWS Well-Architected Framework, SaaS Lens.

For AI agents, the useful question is which tiers hold tenant data. Storage, vector indexes, agent memory and the workers that process data during a run are the tiers a regulated buyer will want siloed. The orchestration layer can be shared, provided the tenant boundary is enforced inside it at runtime and at the data layer.

What per-tenant AI agent infrastructure includes

A per-tenant design for AI agent infrastructure provisions a separate set of resources for each tenant and keeps every component that touches tenant data inside it. In practice that means:

• Dedicated storage for files and documents, in a region the tenant chooses.

• Tenant-owned vector search, so knowledge and memory indexes live in a search service that belongs to the tenant, with no shared index partitioned by a filter.

• Dedicated compute workers for agent runs, so one tenant's tool calls never execute on another tenant's workers.

• Separate environments for development, staging and production within each tenant.

• Scoped keys and identities, with services authenticating through managed identities rather than stored credentials.

• Tenant- and environment-scoped events, so every audit record states which tenant and which environment it came from.

Provisioning this by hand for every tenant does not scale and is hard to audit. Infrastructure as code solves both problems. In Pulumi, a stack is an isolated, independently configurable instance of a program: the same definition is deployed once per tenant and per environment, each deployment has its own configuration and state, and every change shows up as a reviewable diff. The result is reproducible infrastructure with a change history a security team can inspect.

Teams weighing whether to build this layer themselves should cost it honestly. Per-tenant provisioning, upgrades across every tenant stack and teardown on exit are ongoing work, a point we cover in the build vs buy AI platform decision framework.

Isolating environments: development, staging and production stacks

Agents change more often than conventional software. A new tool, a revised prompt or an extra workflow step changes what an agent does with data. Testing those changes against production data, or in the same environment as production agents, is how a test agent ends up writing to a live system.

Separate stacks for development, staging and production, each with its own storage, indexes and workers, remove that path. A change is built in development, piloted in staging against representative data and promoted to production once it passes review. Each environment produces its own audit events, so the record shows where every action ran. Promotion to production is also one of the actions that should wait for a named approver, as set out in our guide to human in the loop for AI agents.

Data residency, keys and network boundaries

Tenant isolation also has a geographic and cryptographic side, and buyers in financial services, legal and the public sector ask about it early:

• Region. Which cloud region holds the tenant's storage, indexes and workers, and can the tenant choose it?

• Encryption. Is data encrypted at rest and in transit, and with which standards?

• Keys. Who controls the encryption keys? Platform-managed keys suit most deployments; regulated tenants often require customer-managed keys.

• Network. Can the tenant's resources connect to its own systems over private networking instead of the public internet?

• Credentials. Do services hold stored secrets, or authenticate through managed identities that can be audited and revoked?

Each answer narrows where tenant data can travel. Taken together with multi-cloud portability, they also decide whether a deployment can move if contract terms, regulation or cloud strategy change.

Five questions to ask about multi-tenant isolation

Questions about data-layer query scoping are covered in our access control article. The infrastructure layer adds five more:

• Where do my vector indexes and agent memory live, and is that search service dedicated to my tenant?

• Do my agents run on dedicated compute workers, or on workers shared with other tenants?

• Is my tenant's infrastructure defined as code, and can you show me its change history?

• Can I choose the cloud and region, and who holds the encryption keys?

• Is every audit event scoped to my tenant and to the environment where the action ran?

A vendor that answers all five with specifics, and can show the evidence, has isolation in its architecture. Vague answers usually mean the boundary depends on configuration.

How Booga Agents isolates each tenant

Booga Agents follows the bridge pattern described above. The core application is managed centrally. Each tenant's storage, vector databases and compute workers are provisioned as dedicated resources on Azure, AWS or GCP, in the region the customer chooses, through per-tenant Pulumi stacks. Those stacks are provisioned automatically, reproducible and auditable.

• Tenant-provisioned vector search. Memory and knowledge indexes live in the tenant's own search service.

• Multi-stack environments. Development, staging and production run as isolated stacks.

• Stack-aware audit and event scoping. Every event is scoped to the tenant and to the specific stack. The audit pipeline covers 14 event categories with a 7-year default retention, configurable per tenant, and streams to the customer's SIEM. Our guide to what an enterprise AI audit trail needs to contain explains why that scoping matters.

• Access control. Capability-level RBAC is enforced at runtime, and 469 dangerous endpoints are blocked from API key access by default.

• Encryption and identity. AES-256 at rest, TLS 1.2+ in transit, and managed-identity key access with no stored credentials.

• Signed events. Webhooks are signed with HMAC-SHA256, with retry and a dead-letter queue.

Enterprise deployments of Booga Agents add customer-managed keys, private networking with VPC peering, data residency per region, and SSO with SCIM. The full architecture is described on the Booga Enterprise platform page.

Onboarding follows the same isolation logic: a 30-minute discovery call, provisioning of the tenant's dedicated infrastructure (typically 5 to 10 business days, depending on procurement), a pilot in a staging stack, then production rollout with SSO and audit streaming to the customer's SIEM.

Booga Agents is available to companies by request. Request access to Booga Agents to discuss dedicated deployment on your cloud and in your region.

Where Booga One fits

Booga One is the self-serve product for individual professionals, and it runs on shared Azure infrastructure: a pool model, suited to one person building and testing agents. When an agent's work needs dedicated infrastructure, its definition, workflows, schedules and report templates move to a dedicated Booga Agents tenant by export and import, and its data is re-ingested from source inside that tenant. Prototype in Booga One. Operationalize in Booga Agents.

Try Booga One free. Free tier, no card required: create your account.

Frequently asked questions

What is multi-tenant isolation for AI agents?

Multi-tenant isolation for AI agents keeps each tenant's data, indexes, memory, compute and events separate from every other tenant on the same platform. For agents it has to cover vector indexes, agent memory and the workers that execute tool calls, in addition to database records and files.

What is the difference between silo, pool and bridge tenancy?

In the AWS SaaS Lens vocabulary, the silo model gives each tenant dedicated resources, the pool model shares resources across tenants with isolation enforced at runtime, and the bridge model combines the two, typically dedicating the tiers that hold tenant data and sharing the rest.

Why do vector databases matter for tenant isolation?

Vector indexes are built from a tenant's documents and power the semantic search agents rely on. A shared index separated only by a filter depends on that filter being applied on every query. A tenant-owned search service removes that dependency.

What is a per-tenant Pulumi stack?

A Pulumi stack is an isolated, independently configurable instance of an infrastructure program. A per-tenant stack deploys the same infrastructure definition separately for each tenant, with its own configuration, state and change history.

Can enterprise AI agents run in my own cloud?

Booga Agents provisions each tenant's storage, vector databases and compute workers on Azure, AWS or GCP in the region the customer chooses, while the core application is managed centrally. Booga Agents is available to companies by request.