Every multi-user software product faces the same problem: many people share one infrastructure, but each person's data has to be private to them. A bug, a misconfiguration, or a single vulnerability anywhere in the stack can leak Y's data to Z and burn the trust of everyone using the product. The category-defining incidents (Notion's 2023 cross-workspace leak, Salesforce's 2024 metadata exposure, several smaller ones in between) all share the same shape: a multi-tenant system that did not enforce isolation rigorously enough at the right layer.
This post is what tenant isolation actually means, why it matters more for an AI agent than for most products, and how Ajeris implements it. We will keep it in plain English; the engineering details are in the security docs.
What "tenant" means
A tenant is one customer of the product. For Ajeris that is one user (for personal accounts) or one business + its team (for business accounts). The tenants are independent of each other; they share no data, no identity, no agent state.
The infrastructure is shared (one database cluster, one application server fleet, one set of integrations) because building a separate stack per tenant would be impossibly expensive. The safety has to come from how the shared infrastructure enforces the per-tenant boundary.
What the boundary protects
Five things, in order of how badly a leak would feel.
- 1MemoryYour episodic, semantic, core memory.
- 2ConversationsEvery message thread on every channel.
- 3Tool credentialsOAuth tokens for Gmail, Plaid, Spotify, Stripe.
- 4Customer data (business)Your business agent's customer records.
- 5Skills + reflectionsProcedural memory + daily reflections.
Of those, tool credentials are the highest-risk category in absolute terms. A leak of Mary's OAuth tokens for her Gmail and Stripe is materially worse than a leak of her conversation history. The encryption layer for credentials is hardened independently of the rest of the data store.
How the isolation actually works
Three layers, defending in depth.
Layer 1: Per-user database partition. Every user-scoped table has a user_id column and the database enforces row-level security on it. Even if the application code accidentally tried to query another user's rows, the database would refuse. This is not a software policy; it is a database rule.
Layer 2: Application-side context wrapping. Every server-side query runs inside a context that scopes to the current user. The application never executes queries without setting the user context first; the absence of context is itself a denial signal at the database layer.
Layer 3: Pre-launch security guards. A set of automated checks run on every commit before deploy: do any new endpoints accept requests without auth, are any new tables missing the user_id column, are any new code paths bypassing the context wrapper. These guards block merges that would silently introduce a tenant-leak vector.
The combination is intentionally redundant. Any single layer failing should be caught by another. The history of multi-tenant security incidents shows that single-layer defenses fail predictably; the value of three layers is that the failures rarely line up.
What this rules out
A few specific failure modes that are off the table.
- Cross-tenant memory leakage. The agent reading Mary's memory while replying to Bob is structurally impossible.
- Cross-tenant tool action. Mary's Stripe being charged for Bob's invoice is structurally impossible.
- Cross-tenant search. Mary's name appearing in search results that Bob is running is structurally impossible.
- Bug-induced leaks via the application layer. An application bug that "forgot" the user context is caught by the database rule before any data is returned.
The thing isolation does NOT rule out: a leak through a side channel (a poorly-configured log file, a metric that aggregates user data, a debug endpoint that bypasses normal auth). These are caught by the pre-launch security guards in turn. The defense is layered; nothing single-pointed is allowed.
What you can verify
Three concrete things a sceptical user can check.
Export your data and inspect. "Export everything you know about me." The agent produces a JSON dump. You can verify nothing in it references other users or aggregated data.
Read the security docs. We publish the security model and vulnerability management policies. They describe the architecture, the guards, and the incident response.
Ask the agent to explain its access. "What do you have access to right now?" The agent answers in plain English: which connectors, which scopes, which channels. You can revoke any of them at any time.
- All user data in one shared table without row-level security.
- Application code is the only thing keeping tenants separate.
- Bugs can leak data; tests are weak.
- Audit story for an enterprise customer is hand-wavy.
- Per-user database partition with row-level security enforced by Postgres.
- Three-layer defense (database + application + pre-launch guards).
- Bugs caught by the lower layer before data is returned.
- Audit story is concrete: here are the guards, here is the architecture.
What we do NOT do (and why we do not)
Honest disclosures about choices that some products make and we do not.
We do not rely on prompts for isolation. Ajeris runs one shared agent service for all users, but no user's data ever sits in another user's context. Every request runs in the requesting user's database context, so row-level security limits it to that user's rows, and the agent keeps no state of its own between requests. The isolation is in the data layer, not in an instruction to the model.
We do not sell user data or use it for advertising. We do use conversations to improve Ajeris, from November 2, 2026, and say exactly how: it is on by default with a switch to turn it off, and your vault, connected accounts and anything made from them, WhatsApp and Telegram chats, health information and voice recordings are never used. The privacy policy has the details.
We do not let third-party developers see user data through the catalog. Skill authors who publish to the catalog see their skill's usage metrics in aggregate; they do not see who installed their skill or what those users did with it.
The trade-off is that some features take longer to ship. We think the trade is right.
Frequently asked
What about my data when I cancel?
Where is the data physically?
What about an Ajeris employee deciding to peek at my data?
Can I run Ajeris on my own infrastructure?
Try it
Ask the agent: "What do you have access to about me, and how is it kept separate from other users?" The answer is the start of trust.
