What Are Multi-Tenant Agents and How Do You Build Them?

Multi-tenant agents are AI agents that serve many users or organizations from one deployment while keeping each tenant's data, memory, and permissions isolated. You need this design as soon as more than one person uses the same agent and those people shouldn't see each other's queries, files, or conversation history. The core requirement is user-scoped execution: every query, memory lookup, and file access runs as the requesting user, not as a shared service account. Vanna 2.0 is one framework that builds this in — its SQL Agent is described as "Open Source • Multi-database • Multi-turn • Access controlled," with optional hosted admin features for access control, observability, agent memory, file system, audit logs, and data retention.

Single-user vs. multi-tenant agents

A single-user agent can hold one set of credentials, one memory store, and one permission level. A multi-tenant agent must resolve all three per request.

The failure mode to avoid is "confused deputy" behavior: the agent runs with broad service credentials and a user tricks it into reading another tenant's data. Isolation has to be enforced at execution time, not just in the UI.

Scope execution per user

The central design rule: the agent should never hold credentials broader than the current user's. Each request carries an identity, and that identity determines what the agent can query, remember, and read.

Concretely, for a SQL agent this means:

1. Input — the user's natural-language question plus their authenticated identity (from your app's session or token).
2. Action — the agent generates SQL and executes it through a connection scoped to that user's permissions, not a shared admin connection.
3. Expected result — the user sees only rows their identity is allowed to see; the same question from a different tenant returns that tenant's data or nothing.

If you can't scope the database connection per user, enforce row-level security in the database itself and pass the tenant ID into every query. Either way, the isolation lives below the LLM, so a prompt injection can't cross tenants.

The same applies to memory and files. Agent memory (a vector store of past interactions) and any file storage must be partitioned by tenant. Vanna lists "Agent Memory: Hosted vector DB" and "File System: Secure file storage" as admin features, which is the layer where this partitioning normally happens.

Access control, audit logs, and retention

Isolation is necessary but not sufficient for production. You also need to answer "who did what, and can we prove it later?"

• Access control — decide who sees what. Map each user to a tenant and a role, and check that mapping before any data access. Vanna lists "Access Control: Control who sees what" as a hosted admin feature.
• Audit logs — record every query, its author, and its result scope. Vanna lists "Audit Logs: Comprehensive activity tracking & compliance."
• Observability — per-tenant metrics and distributed tracing so you can see which tenant is slow, erroring, or hitting limits. Vanna lists "Observability: Real-time metrics & distributed tracing."
• Data retention — conversations and logs accumulate fast across many tenants. Vanna lists "Data Retention: Long-term storage for conversations & logs," which is where you set per-tenant retention windows.

These are the features that turn a working demo into something you can operate for many customers. Note that Vanna presents them as optional hosted admin features, so the open-source framework alone doesn't give you the managed versions — plan for that distinction when choosing self-host vs. cloud.

Quotas and cost control across tenants

With one tenant, a runaway query is an annoyance. With many, one tenant can consume the shared LLM and database budget. Vanna's site lists quota management among its production features, alongside user-scoped execution and rich UI components. Design for:

• Per-tenant request or token limits.
• Per-tenant storage and retention caps.
• Alerts when a tenant approaches its limit.

Without per-tenant quotas, noisy-neighbor problems are inevitable.

Choosing a stack

Vanna works with any LLM provider and database, which matters for multi-tenant deployments because different tenants may need different backends. The site lists LLM providers (Anthropic, OpenAI, Gemini, Ollama) and databases (SQLite, PostgreSQL, MySQL, Snowflake, BigQuery, and others via docs).

Two practical decisions:

• Self-host vs. cloud. The framework is open source; the admin features (access control, observability, memory, file system, audit logs, retention) are optional hosted features. If you need those managed, check pricing; if you need full control, self-host and build the equivalent.
• Vendor lock-in. Vanna advertises "no vendor lock-in," and the provider/database matrix supports that — you can swap LLMs or databases per deployment. Verify this against your own requirements rather than assuming it.

For a first build, the fastest path is the SQL Agent over a single database with per-user connection scoping, then add memory partitioning, audit logs, and quotas as you onboard more tenants. The Colab dummy-database option is listed as a 1-minute, no-sign-in start; the pip install path is listed at about 30 minutes.

Common failure points

• Shared service credentials. The agent runs as an admin account and relies on the LLM to "not" leak data. Fix: scope credentials per user or enforce row-level security.
• Unpartitioned memory. All tenants share one vector store, so one tenant's history surfaces in another's answers. Fix: partition memory by tenant ID.
• No audit trail. You can't reconstruct who saw what. Fix: log every query with author and scope.
• Missing quotas. One tenant exhausts shared budget. Fix: per-tenant limits and alerts.
• Assuming OSS includes admin features. The hosted admin features are optional and separate. Fix: confirm what's in the open-source framework vs. the hosted offering before committing.