Multi-Tenant Agent Memory: Scoping, Authorization, and Isolation

Multi-tenant agent memory needs authorization on every read and write, plus a stable scope attached to the data. A container tag or namespace helps select the right memory. It is not a substitute for checking which tenant and user the caller may access.

A useful test is simple: give two tenants similar conversations and the same local user ID. A request authenticated for tenant A must never return tenant B's context, even if the query is a better semantic match for B's data.

Does every tenant need a separate memory database?

Not necessarily. A shared store with enforced authorization and scoped queries can support logical separation. Separate databases or deployments may be appropriate when contractual boundaries, recovery requirements, or resource isolation demand them. A namespace alone establishes neither access authorization nor dedicated capacity.

Decide whether memory belongs to one person, a team, or a whole tenant before choosing the storage boundary. For shared knowledge sources, the connector permissions guide explains why permission changes must reach retrieval. The lifecycle guide covers what to verify when a tenant or user leaves.

Derive scope on the server

Resolve tenant membership and user identity from a trusted session or service identity. Then map that pair to the memory scope. Do not accept an arbitrary container identifier from a browser request and pass it through using a privileged API key.

For example, an application could maintain this mapping:

authenticated tenant + authenticated user → application-owned scope ID

An opaque identifier avoids embedding email addresses or other personal details in keys. The important property is a stable, unambiguous mapping, not a particular string format.

When using Supermemory's AI SDK integration, containerTag selects the memory scope and customId identifies the conversation document. Keep the scope stable across sessions that should share memory. Give distinct conversations distinct document identifiers.

Enforce the boundary at every entry point

Operation	Required check
Write or import	Caller may add data to the resolved scope
Search or profile lookup	Caller may read that scope before retrieval runs
Fetch by document ID	The document belongs to an allowed scope
Update, delete, or export	Permission covers both the object and the operation
Background processing	Job retains the original authorized scope
Cache lookup	Cache key includes the relevant tenant and permission context

Stamping a tenant ID at ingestion does not make an unscoped read safe. Filtering only after results enter the model prompt is too late. Apply the access constraint before returning context to the agent.

Separate personal and shared knowledge deliberately

Some information belongs to one user; some belongs to a team. A support agent might need a customer's ticket history and the company's shared troubleshooting guide. Authorize these sources separately and preserve their provenance when combining them.

Do not infer permission from similarity or from the agent's requested task. “Search all customer tickets” is a request, not an authorization grant. Likewise, switching agent roles should not automatically grant access to another team's memory.

When membership changes, check what happens to sessions, caches, queued jobs, and previously retrieved context. Revoking access in the source application is useful only if downstream retrieval reflects the change within an understood interval.

Choose physical separation for a stated requirement

Logical isolation can use a shared database with enforced authorization. Dedicated databases or deployments provide different failure boundaries and operating costs. Neither architecture removes the need for application authorization and correct credential handling.

Evaluate separation against the actual requirement: customer-managed infrastructure, region restrictions, workload isolation, credential boundaries, or recovery procedures. Avoid treating a separate index as proof that infrastructure is dedicated; that depends on the implementation.

Test isolation with adversarial examples

Use a small synthetic dataset that you can inspect without exposing customer data. Include:

1. Two tenants with the same local user ID and different private facts.
2. A request that supplies another tenant's container ID.
3. A direct document lookup for an object outside the caller's scope.
4. A cache hit following a tenant switch in the same browser session.
5. A queued write processed after the user's access was revoked.
6. A shared document whose access is removed after ingestion.
7. A retry that accidentally loses its original scope.

Check returned objects and the final model input, not just the answer. A model failing to mention leaked data does not mean the retrieval boundary held.

Treat deletion as a lifecycle operation

Supermemory documents a container deletion endpoint for a container and its associated documents and memories, restricted to organization owners and administrators. Your application must also handle copies it controls, such as exported transcripts, caches, and logs.

Pause or invalidate pending ingestion that could recreate deleted content. After deletion, check document retrieval, memory search, profile retrieval, and cached responses within the system's documented processing behavior.

Measure noisy-neighbor effects separately

Correct authorization does not guarantee fair use of shared resources. A large ingestion job can compete for capacity even when it cannot read another tenant's data.

Measure per-tenant ingestion lag, errors, retrieval latency, and resource consumption during a concurrent load test. Consider quotas, scheduling, and workload separation where the results justify them. A global average can hide a poor experience for a smaller tenant.

The release criterion is evidence: the intended scopes work, forbidden scopes fail, and background paths preserve the same rules. Keep those tests when changing SDKs, introducing new tools, or adding a connector.

For the related implementation, see Supermemory with TanStack Start: A Server-Side Memory Boundary.

To evaluate Supermemory in your application, start a two-tenant pilot using fictional records. Apply your authorization checks to both write and retrieval paths, then run the cross-tenant and deletion cases above before adding real customer data.