Multi-Tenant AI Agents: One Agent Per Customer, Isolated by Default

If you're putting AI agents into a product with more than one customer, the central requirement is isolation: customer A's agent must never touch customer B's data, money, or credentials. Multi-tenant AI agents solve this by giving each customer their own agent, isolated by default — not one shared agent with a system prompt that politely asks it to stay in its lane.

This is the identity layer of the multi-tenant playbook: get it right and every other concern — permissions, secrets, spend — has a clean boundary to attach to. Here's the model Naïve uses and how to wire it up.

Why isn't one shared agent enough?

The shortcut is a single agent instructed to "only act for the current user." It demos well and fails in production. A prompt is a suggestion, and the ways it breaks are mundane: a prompt-injection payload in a document the agent reads, a mixed-up variable, a cache that outlives a request, a log line that captures another tenant's data.

Isolation that depends on the model behaving is not isolation. In a multi-tenant product, the blast radius of one slip is a real customer's account — so the boundary has to sit below the model, in infrastructure the prompt can't override.

What does "one agent per customer" actually look like?

Naïve models multi-tenancy in three layers:

Operator (your company)      ← you, the developer who signed up
  └── Account Kit            ← policy template: what a user's agent can do
        └── tenant user      ← one of your customers
              └── resources  ← cards, inboxes, vault, connections, sessions, ...

• Operator is your workspace. It holds your API keys and your Account Kits.
• Account Kit is a reusable policy template that says which primitives are enabled and which third-party apps a user may connect.
• Tenant user is one of your customers. Crucially, it is not an auth subject — it never signs in. It's an opaque record you manage through the API, SDK, or CLI, and every resource the agent creates belongs to exactly one tenant user.

That last point is the whole game: cards, inboxes, vault entries, connections, and sessions each attach to a single tenant user, so isolation is a property of the data model rather than a runtime hope.

How does per-user isolation compare to a DIY build?

How do you wire it up?

Two calls cover the common case. Create a tenant user when a customer signs up, then scope every agent action to that user:

import { Naive } from "@usenaive-sdk/server";
const naive = new Naive({ apiKey: process.env.NAIVE_API_KEY! });
 
// on signup: one tenant user per customer
const user = await naive.users.create({ email: "customer@acme.com" });
 
// every call the agent makes is now isolated to that customer
const agent = naive.forUser(user.id);
await agent.email.send({ to: "lead@example.com", subject: "Hi", body: "..." });

The same surface works from the CLI (--user), MCP (a user_id argument), and REST (/v1/users/:user_id/...). And it scales down as cleanly as it scales up: a solo developer gets a default Account Kit and a default tenant user automatically, so calls with no explicit user just resolve to that default (per published docs).

Where does policy come in?

Isolation answers "whose resources?" — it doesn't answer "what is this agent allowed to do?" That's the job of the Account Kit you assign to each tenant user: it defines which primitives are enabled and which apps can be connected, enforced on every call. You author a few kits (say, Starter/Pro/Enterprise) rather than configuring ten thousand users one at a time.

That permission layer is covered in AI agent permissions, enforced at execution time, and the credentials each isolated agent holds are covered in secrets management for AI agents.

Where to start

Model one customer as a tenant user and route a single real action through forUser — send an email, read a connected inbox, make a small purchase. Confirm the resource comes back attached to that user and is invisible to another. Once one tenant is isolated end to end, every customer after that is the same two calls. The multi-tenancy docs are the source of truth for the model and the dual-mode resolution rules.