Trust and control
Multi-tenant AI agents: keeping each customer’s data, keys and limits apart
A multi-tenant AI agent platform runs agents for many customers, called tenants, on shared infrastructure while keeping each tenant’s data, credentials, settings and spending apart. Done well, one tenant’s agent can never read another tenant’s records, use its credentials or spend its budget.
Updated · 5 min read
Why does multi-tenancy matter more for AI agents?
Agents hold credentials to real systems, read sensitive content and act on their own. A mistake between tenants is not only a leak of data, it can be an action taken in the wrong customer’s CRM. Three kinds of teams run into this first:
- Agencies that build and run agents for many clients.
- Software companies that put agents inside their own product, one tenant per customer.
- Large companies that keep business units or regions apart.
What has to be kept apart?
| What | Examples | How it is kept apart |
|---|---|---|
| Data | Conversations, runs, files, settings | Every query limited to one tenant |
| Credentials | CRM tokens, API keys, database passwords | Encrypted per tenant, opened only for the call |
| Encryption keys | The keys that protect stored content | Separate data keys for each tenant |
| Policy and settings | Allowed models, allowed hosts, branding | Inherited down a tree, but scoped |
| Spending | Model costs, usage | Metered and budgeted per tenant |
| People | Who may act in which tenant | No access across tenants without a grant |
Data
- Examples
- Conversations, runs, files, settings
- How it is kept apart
- Every query limited to one tenant
Credentials
- Examples
- CRM tokens, API keys, database passwords
- How it is kept apart
- Encrypted per tenant, opened only for the call
Encryption keys
- Examples
- The keys that protect stored content
- How it is kept apart
- Separate data keys for each tenant
Policy and settings
- Examples
- Allowed models, allowed hosts, branding
- How it is kept apart
- Inherited down a tree, but scoped
Spending
- Examples
- Model costs, usage
- How it is kept apart
- Metered and budgeted per tenant
People
- Examples
- Who may act in which tenant
- How it is kept apart
- No access across tenants without a grant
How do you isolate each tenant’s data?
There are three common designs: a separate database for each tenant, a separate schema for each tenant, or shared tables where every row carries its tenant and the database filters every query. Separate databases are strong but costly at scale. Shared tables are efficient, and safe only if the database itself enforces the filter, so that one forgotten condition in the code cannot leak data.
MyDeepAgents uses shared tables with Postgres row-level security. Every tenant table has row-level security switched on and forced, with a policy that compares each row’s tenant with the tenant set for the current transaction. The tenant is set inside each transaction, and if it is missing no rows match at all, so the system fails closed. A check on every database migration refuses a new tenant table without forced row-level security.
How are credentials and encryption keys kept per tenant?
In MyDeepAgents, stored content is encrypted with AES-256 data keys that belong to one tenant and one purpose. Each data key is kept wrapped by a key in AWS Key Management Service, and the wrapping is bound to the tenant, so one tenant’s wrapped key cannot be opened as another tenant’s. Each part of the platform may only use the key purposes it needs.
Credentials for connected tools are sealed under the tenant’s own credentials key. The API that serves the console never reads a stored secret. Only the worker that makes outbound calls opens it, at the moment of the call, and secrets are never put into a prompt or sent to a browser.
How do settings, limits and branding work across many tenants?
Tenants in MyDeepAgents form a tree: a platform or an agency at the top, its customers below, and their teams below them, six levels deep by default and ten at most. Settings flow down the tree:
- A child inherits its parent’s settings unless it sets its own.
- Some settings can only be narrowed by a child, never widened, such as the allowed model providers, the allowed models and the hosts agents may call.
- A parent can lock a setting, so the tenants below it cannot change it.
- Every value shows which tenant it came from, so nobody has to guess why an agent behaves as it does.
- Branding merges down the tree, so a partner’s look carries through to its customers.
How do you stop one tenant from spending another’s budget?
Every model call in MyDeepAgents is metered with its tenant, model, tokens and cost. On top of that:
- Per run: a cost cap on every agent run, $0.50 by default, counted at list price whoever’s key is used.
- Per organization and workspace: monthly and daily budgets, either soft (alerts at 50, 80 and 100 percent) or hard (the next call is refused). An organization’s budget counts its own spending and that of every organization below it.
- Own keys: each organization can add its own key for each model provider. The platform uses the organization’s own key first, then a key its parent shares with it.
Money budgets apply to calls made on keys the platform provides. When a tenant uses its own provider key, the provider bills that tenant directly, and the per-run cap still applies.
How can a parent help a child tenant without seeing everything?
Through delegation. In MyDeepAgents a delegation is a grant between two tenants that names the role, the workspaces, the most sensitive class of data it covers, conditions such as multi-factor sign-in or an address range, and, if you want, an end date. Every action taken under a delegation is recorded in the audit log with the delegation’s ID, and the console shows a banner while someone is acting for another tenant.
Tenants under the HIPAA profile approve every delegation themselves; nothing is accepted for them automatically. One exception to keep in mind: when a parent creates a managed child tenant, the parent gets an admin delegation to it automatically.
Key points
- Multi-tenancy keeps each customer’s data, credentials, settings and spending apart on shared infrastructure.
- Let the database enforce isolation, so a single bug in the code cannot leak data.
- MyDeepAgents uses forced Postgres row-level security, per-tenant AES-256 data keys and sealed credentials.
- Settings flow down a tenant tree; some can only be narrowed, and parents can lock them.
- Budgets, per-run caps and scoped, audited delegations keep money and access inside each tenant.
Questions people also ask
Is row-level security enough to isolate tenants on its own?
It is the most important layer, but not the only one. Keep it alongside per-tenant encryption keys, permission checks on every request and an audit log, so a failure in one layer is caught by another.
How deep can tenants nest in MyDeepAgents?
Six levels below the platform by default, and up to ten.
Can each tenant use its own AI model provider key?
Yes. Each organization can add its own key for each provider. The platform uses the organization’s own key first, then a key its parent shares with it, and the provider bills the key’s owner.
Can a parent tenant see its children’s data?
Only through a delegation, which names a role, workspaces and data class, can end on a date, and is recorded in the audit log. A parent that creates a managed child gets an admin delegation to it automatically.