Tenant Isolation in a Multi-Agent SaaS

TL;DR

›Tenant isolation in a multi-agent SaaS is structural: every card, inbox, vault entry, and connection belongs to exactly one tenant user.
›Enforce it with naive.forUser(customerId) on every agent call — a scoped client cannot reach another user's resources.
›Isolation is not a prompt instruction ('only act for the current user') — prompts can be injected; platform boundaries cannot.
›Verify before launch: create two tenant users, run the same action on both, confirm zero cross-reads.
›Account Kits add a second layer — even within one tenant, policy bounds what the agent may do.
›OAuth connections and MCP sessions inherit the tenant user scope — mint sessions per user, never share tokens.

You shipped multi-tenant auth in your SaaS. Your agent has a clever system prompt: "only act for the current user." That is not tenant isolation — it is a hope. Tenant isolation in a multi-agent SaaS means the platform rejects cross-tenant access even when the model misbehaves.

Multi-tenant AI agents explains the model. This post is the pre-production checklist for builders wiring Naïve today.

The isolation invariant

Every resource — cards, inboxes, vault entries, connections, sessions — attaches to exactly one tenant user. A scoped client can only reach that user's IDs.

Operator
  └── Account Kit (policy)
        └── tenant user A  →  resources {A}
        └── tenant user B  →  resources {B}

No shared bucket. No "current tenant" variable the model supplies.

Checklist: wiring

Step	Pass criteria
Create user on signup	`users.create()` per customer; store `tenant_user_id` in your DB
Scope every agent call	`naive.forUser(storedId)` — never the raw workspace client for customer actions
Mint sessions per user	One MCP session per customer run — see what is an MCP session
Per-user OAuth	Connections on the tenant user — see OAuth for AI agents
Assign kits by tier	Starter/Pro/Enterprise kits — not bespoke per-user JSON in app code

Checklist: testing

Run this before production:

Create Alice and Bob as tenant users
Alice's agent stores vault.put("key", "secret-a")
Bob's scoped client calls vault.reveal("key") → must fail (not-found or forbidden)
Repeat for cards list, email send, connections list
Add to CI — isolation regressions are silent until a customer reports a leak

Failure modes (avoid these)

Anti-pattern	Why it breaks
Tenant ID in the prompt	Injection swaps the ID
Shared MCP session	All customers ride one credential
Workspace key in the agent runtime	One leak exposes every tenant
Global in-memory cache keyed wrong	Cross-tenant data in one process

Isolation + policy

Isolation without Account Kits means Customer A's agent might still issue cards if your kit allows it — correctly, but dangerously. Tighten kits per tier after isolation tests pass.

Where to go next

Building AI Agents Into Your SaaS — full playbook
What is an AI agent identity? — definitional
Multi-tenancy docs — subject resolution rules

Frequently Asked Questions

What is tenant isolation for AI agents?+

It means Customer A's agent cannot read, spend, or send as Customer B — ever. On Naïve, isolation is a property of the data model: every resource attaches to one tenant user, and naive.forUser(id) scopes API, SDK, MCP, and CLI calls to that user. A bug in your prompt cannot cross the boundary because the platform rejects out-of-scope resource IDs.

How is this different from multi-tenant AI agents?+

Multi-tenant AI agents is the concept — one agent per customer, the Operator → Account Kit → tenant user model. This post is the implementation checklist: how to wire forUser, what to test, and the failure modes that bypass isolation if you cut corners.

What is the most common isolation mistake?+

Using one workspace key and passing a tenant ID as a tool argument the model controls. A prompt injection can swap the ID. The fix is server-side scoping: resolve the tenant user from your authenticated session, call forUser(thatId), and never let the model choose the isolation boundary.

Do MCP sessions preserve tenant isolation?+

Yes — each session is minted for one tenant user. A session for User A cannot list or mutate User B's resources. Mint sessions in your backend after you know which customer the run belongs to; do not reuse one session across customers.

How do I test tenant isolation before shipping?+

Create tenant users Alice and Bob. Run the same governed action for each (send email, issue card, vault put). Attempt to read Alice's resource IDs from Bob's scoped client — expect not-found or forbidden. Automate this as an integration test in CI.

Does tenant isolation replace permission policy?+

No. Isolation answers whose resources; Account Kits answer what the agent may do with them. You need both — isolated but over-permissioned is still dangerous; well-permissioned but shared is still a cross-tenant leak.

Naïve Team

Building the agent-native backend.

Keep reading

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

Multi-tenant AI agents give every customer their own isolated agent. Here's the operator, tenant-user, and Account Kit model behind per-user isolation.

What Is an AI Agent Identity?

An AI agent identity is the governed record an agent acts as — tenant user, Account Kit, resources, and audit trail — not the model or the API key alone.

Building AI Agents Into Your SaaS: The Multi-Tenant Playbook

Building multi-tenant AI agents into your SaaS means giving each customer an isolated, governed agent. Here's the full architecture and how to ship it.

OAuth for AI Agents: Per-User Connections

OAuth for AI agents should be per-user: each tenant connects their own apps — scoped by Account Kit, stored as connections, not shared tokens.