Multi-tenancy is an architecture in which a single software instance, together with its underlying database and hardware, serves multiple tenants whose data is isolated and invisible to one another. A tenant is usually a customer organization, and the central engineering question is how much of the stack those tenants share and where the boundary between them is enforced. This guide covers the isolation models, the risks, the controls and tests that matter, and the additional requirements that appear when the tenant workload is an AI agent.
TL;DR
- Multi-tenancy means tenants share an application instance and infrastructure while their data stays logically isolated. Single tenancy gives each tenant its own application, database and hardware.
- Database isolation falls into three patterns: silo (a dedicated stack and database per tenant), bridge (a shared database instance with a schema per tenant) and pool (shared tables separated by a tenant identifier).
- More sharing generally lowers cost but widens the blast radius of security flaws, performance contention and outages, so isolation is best treated as a spectrum rather than a binary choice.
- Tenant context must come from verified identity, never from client input, and cross-tenant access must be covered by negative-path tests.
- Agent products add new tenant data (vector indexes, session files, tool state) and new execution risk (agent-run code), and both need explicit isolation.
What multi-tenancy means in software
Picture one deployed application receiving requests from two companies. Both companies log in to the same running code, query the same database server and use the same compute pool, yet neither can read, modify or even detect the other's records. That arrangement is multi-tenancy.
The components that recur across vendor and platform guidance are tenants, shared resources and data isolation. SAP's reference architecture, published in January 2025, expands this into tenant identity, tenant isolation, a shared software instance, shared resources, access controls, identity management, performance controls and onboarding and offboarding. The last item is often underestimated: a tenant lifecycle that provisions and removes data reliably is as much a part of the architecture as the query filter.
Multi-tenancy is not the same as SaaS
The two terms are frequently used as synonyms, but they describe different things. According to Azure's architecture guidance, SaaS is a business model, whereas multitenancy is an architectural concept for sharing components among tenants. A SaaS product can use different tenancy models, and multitenancy can exist outside SaaS, for example in an internal platform that serves several business units.
Multi-tenancy versus single tenancy
In a single-tenant deployment, each tenant receives its own application, database and supporting hardware. In a multi-tenant deployment the instance is shared and the separation is logical. Neither is universally better. Single tenancy simplifies per-customer customization and containment of failures, while multi-tenancy simplifies operations and spreads fixed costs across many customers.
Multi-tenancy versus virtualization
Virtualization partitions physical hardware into virtual machines, each running its own operating system, and it is an infrastructure technique. Multi-tenancy is a design decision at the application and data layers that can sit on top of virtual machines, containers or bare metal. A multi-tenant application may run on virtualized hosts, and a single-tenant application may run on them as well, so the two answer different questions: how is hardware divided, and how are customers divided.
The three data isolation models
AWS's multi-tenant guidance describes three database models: silo, bridge and pool.
| Model | What is shared | What is dedicated | Main trade-off |
|---|---|---|---|
| Silo | Nothing at the application or database layer | Application stack and database per tenant | Strongest separation, highest infrastructure and setup cost |
| Bridge | Application stack and database instance | A schema per tenant | Moderate separation, schema migrations multiply with tenant count |
| Pool | Application stack, database instance and tables | Nothing; rows carry a tenant identifier | Lowest cost, isolation depends entirely on enforced policy |
The AWS Database Blog notes that silo provides the strongest separation at the price of more infrastructure and setup cost, that bridge shares a database instance with one schema per tenant, and that pool places tenant rows side by side using a tenant identifier.
Isolation as a spectrum
The three labels suggest a tidy choice, but production systems rarely follow it. Microsoft presents isolation as a spectrum from shared-nothing to shared-everything, in which compute, databases, networking and domains can each be isolated or shared independently. Its storage guidance adds that isolation can use separate tables, containers, databases, accounts, servers or subscriptions, or combinations of these, depending on tenant requirements.
A practical consequence is the hybrid design. A product might pool small tenants in shared tables, place regulated customers in dedicated databases and run every tenant on the same stateless API tier. The tenancy model is chosen per component, not once for the whole system.
Benefits of multi-tenancy
- Lower unit cost. Microsoft states that greater sharing generally lowers cost. Idle capacity for one tenant serves another.
- Simpler operations. One deployment to patch, monitor and release replaces many.
- Faster onboarding. Creating a tenant becomes a data operation rather than an infrastructure project.
- Consistent product. Every tenant runs the same version, which removes the long tail of customer-specific forks.
Risks and what they cost
The same Azure guidance warns that greater sharing can worsen security exposure, performance contention and outage scope, while dedicated infrastructure accommodates tenant-specific requirements better. The OWASP Multi-Tenant Security Cheat Sheet gives the most complete catalogue of multi-tenant risks:
- cross-tenant data leakage and tenant impersonation
- broken isolation and insecure direct object references (IDOR)
- noisy-neighbor attacks, where one tenant degrades others
- cross-tenant privilege escalation and tenant-context injection
- shared-resource poisoning
- insecure onboarding and offboarding
- audit gaps
Microsoft also lists the reasons to move toward stronger isolation: tenant-owned encryption keys, individual backup and restore policies, data in different geographic locations, compliance needs and noisy-neighbor concerns. If a single enterprise customer requires any of these, that tenant is a candidate for a siloed or bridged placement even when the rest of the product is pooled.
Designing tenant isolation that holds
1. Derive tenant context from verified identity
OWASP's guidance is to derive tenant context from verified identity and membership and to enforce tenant ownership at tenant-scoped resource boundaries. A tenant identifier supplied in a request body, query string or header is an input to be validated against the authenticated principal, never a source of truth. Tenant-context injection and IDOR both begin when that rule is broken.
2. Pick the database boundary deliberately
OWASP recommends selecting separate databases, separate schemas, shared row-level tables or a hybrid according to security, compliance and operational requirements. For the pool model it states that shared-table isolation requires enforceable ownership, policy coverage, constrained request roles and negative-path tests.
3. Use row-level security for pooled tables
For PostgreSQL, AWS Prescriptive Guidance recommends row-level security for pooled models, with policies that compare a tenant column to a runtime tenant context. It prefers that runtime context to creating a database user for every tenant, and it recommends enabling row-level security on every table that contains tenant data. Its examples use PostgreSQL's current_setting function with an application tenant identifier. PostgreSQL's own documentation on row security policies also notes that a table's owner is typically not subject to those policies, which is why the application should connect with a constrained role rather than the owner.
A minimal pattern looks like this:
ALTER TABLE sessions ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON sessions
USING (tenant_id = current_setting('app.tenant_id')::uuid);The application sets app.tenant_id per transaction from the verified identity. Connection pooling deserves attention here, because a context left over from a previous request on a reused connection is a cross-tenant leak.
4. Keep the tenant identifier consistent across stores
The AWS Generative AI Atlas recommends using the same tenant identifier across every data location, using a tenant-specific partition key in NoSQL systems, and routing SQL access through dedicated data-access classes so that tenant filters are not accidentally omitted.
5. Test the negative paths
Positive tests show that a tenant can read its own data. Isolation is proved by the opposite cases. OWASP's recommendations cover testing cross-tenant access, request roles and connection reuse, and logging tenant-scoped security events. The same AWS atlas states that unit testing is critical for confirming that insecure tenant-filtering code has not been introduced. A useful baseline suite includes:
- Tenant A requests a resource ID belonging to tenant B and must receive a not-found or forbidden response.
- A request with a forged tenant header must be rejected or ignored.
- Two sequential requests from different tenants on the same pooled connection must see different data.
- A background job must carry and apply the tenant context of the task that created it.
- Offboarding must remove tenant data from every store, including caches and indexes.
Multi-tenancy for AI agent products
Agents change the picture in two ways. First, tenant data spreads across more stores. The AWS Generative AI Atlas notes that AI applications may hold tenant data in object storage, SQL or NoSQL databases, vector indexes for RAG and graph databases, so ownership and isolation must span all of them. AWS's guidance on multi-tenant agentic AI states that agent architectures need constructs and mechanisms to enforce an agent's tenant-isolation requirements, which extends the concern beyond ordinary application data.
Second, agents execute. A coding agent reads files, runs commands and calls tools on behalf of a tenant, so the runtime is itself a shared resource that needs a boundary. In practice a multi-tenant agent product should answer these questions for every tenant:
- Which sandbox or environment does this tenant's session run in, and is it ever reused by another tenant?
- Where are session transcripts, uploaded files and agent memory stored, and what key scopes them?
- Which credentials does the agent hold, and can they reach another tenant's resources?
- What limits stop one tenant's long-running agent task from starving the rest?
We cover the sandbox decision in more detail in our piece on AI agent sandboxing, and the surrounding layers in the AI agent stack overview. For readers weighing hosted agents as a delivery model, Agent as a Service describes where the tenant boundary tends to fall.
Our perspective on tenancy for agent products
We build HarnessRouter as an open-source unified interface that lets product teams plug Codex, Claude Code, Hermes and other supported agent harnesses into their products through one Agent API. From that vantage point, the recurring mistake we see is treating tenancy as a database concern only. In an agent product the tenant boundary also runs through the session, the file store, the provisioned environment and the lifecycle of the agent runtime.
That is the reason we think the integration layer should present sessions, files, plugins and environments as first-class, separately addressable resources. When each of those has its own identity, a product can attach a tenant identifier to all of them and enforce it consistently, instead of discovering later that a harness stored state somewhere the tenant filter never reached. It also keeps the harness swappable: the isolation policy belongs to the product, not to whichever agent happens to run today, a point we develop in agent harness vs model.
Our practical advice is to decide the isolation tier per tenant class early. Pool small accounts, reserve dedicated environments for customers with compliance or key-ownership requirements, and write the cross-tenant negative tests before the second customer arrives rather than after the tenth.
Running a multi-tenant agent product on HarnessRouter
HarnessRouter gives product teams one Agent API across more than 30 agent harnesses, with agent session management, file handling, plugin support, environment provisioning, benchmarking tools and serverless agent runtime lifecycle features. You can start on the Free plan at $0 per month, move to Developer at $20 per month, and scale through Production at $200 per month and Scale at $1,000 per month. Enterprise has no published price, and usage-based fees such as tracing at $50 per month are listed on the pricing page.
Teams that prefer to operate the stack themselves can use the self-hosted HarnessRouter Community Edition, and the agent product examples show how other products structure sessions and environments.
A checklist before you ship
| Area | Question to settle |
|---|---|
| Identity | Is the tenant derived from the authenticated principal on every request? |
| Data | Does every table, bucket, index and cache key carry the same tenant identifier? |
| Database | Is row-level security enabled on each tenant table, and does the app use a non-owner role? |
| Runtime | Is each agent session executed in an environment that cannot reach other tenants? |
| Capacity | Are per-tenant rate and resource limits in place? |
| Observability | Are security events logged with the tenant identifier? |
| Lifecycle | Does offboarding delete data from all stores? |
| Testing | Do negative-path tests run in continuous integration? |
FAQ
What is multitenancy in SaaS and what are its key components?
It is an architecture where one software instance serves many customers, called tenants, whose data is isolated from one another. The key components are the tenants themselves, the shared resources and the data isolation mechanism, supported by identity, access control, performance controls and onboarding and offboarding. SaaS is the business model; multitenancy is one way to build it.
Which isolation model should I choose: silo, bridge or pool?
Choose according to security, compliance and operational requirements, not by default. Pool is the cheapest and depends on enforced row-level policies, silo gives the strongest separation at higher cost, and bridge sits between them. Many products combine them, pooling small tenants and siloing those with strict requirements.
Is multitenancy the same as virtualization?
No. Virtualization divides hardware into virtual machines, while multitenancy divides customers within an application and its data layer. A multi-tenant application can run on virtual machines, containers or physical servers.
Do AI agents need different tenant isolation from ordinary web apps?
Yes, in two respects. Agent products keep tenant data in more stores, such as vector indexes and object storage, and agents execute code and call tools, so the runtime needs its own boundary. AWS guidance on agentic AI says agent architectures need explicit mechanisms to enforce tenant isolation.
Sources
- What Is Multi-Tenant? | IBM
- Multitenant SaaS Application on SAP BTP using CAP | SAP Architecture Center
- SaaS and Multitenant Solution Architecture | Microsoft Azure
- Guidance for Multi-Tenant Architectures on AWS
- Multi-tenant data isolation with PostgreSQL Row Level Security | AWS Database Blog
- Tenancy Models for a Multitenant Solution | Microsoft Azure
- Architectural Approaches for Storage and Data in Multitenant Solutions | Microsoft Azure
- Multi Tenant Security Cheat Sheet | OWASP
- Implementing managed PostgreSQL for multi-tenant SaaS | AWS Prescriptive Guidance
- Building multi-tenant agentic AI | AWS Prescriptive Guidance
- Multi-tenant Security | Generative AI Atlas
- Row Security Policies | PostgreSQL documentation