Multi-tenant AI memory without cross-customer leaks

What is multi-tenant AI memory?

Multi-tenant AI memory stores durable facts for several customers or organizations in one product without allowing one tenant’s context to appear in another tenant’s request. Isolation must cover writes, search, reranking, graph traversal, summaries, export, deletion, and the audit path.

A vector index shared across tenants can still support isolation when every query enforces the tenant boundary. What matters is whether the control is mandatory, testable, and present in every code path rather than optional metadata supplied by a model.

Which scopes should every memory request carry?

Start with the tenant, then add the user, agent, project, and session dimensions needed by the product. Scope resolution should come from authentication, routing, and the application database, not from generated text.

How should AI memory enforce tenant isolation?

Attach the tenant ID to every record and require it on every search. Enforce the filter inside the memory service before similarity ranking or graph traversal. Return a scope violation as a hard error when tenant resolution fails; never fall back to a default or global tenant.

Avoid application patterns where one raw query object is passed around without its authorization context. Build a small trusted wrapper that accepts an authenticated principal and exposes only scoped read and write methods.

type Principal = {
  tenantId: string;
  userId: string;
  agentId: string;
};

function scopedSearch(memory: Memory, principal: Principal, query: string) {
  if (!principal.tenantId || !principal.userId) {
    throw new Error('Memory scope cannot be resolved');
  }

  return memory.search({
    query,
    userId: principal.userId,
    agentId: principal.agentId,
    metadata: { tenant: principal.tenantId },
    limit: 8,
  });
}

How do you test for cross-tenant memory leaks?

Create at least two tenants with deliberately similar users, agents, projects, and vocabulary. A leak is easier to catch when the expected answer differs by only a tenant-specific detail. Keep scope violations as binary failures rather than averaging them into a quality score.

How should tenant deletion and export work?

Deletion must name every durable surface: input events, extracted memories, versions, graph relationships, derived summaries, embeddings, caches, analytics copies that identify the tenant, and exports still under application control. Define backup replay so a restored copy does not bring deleted data back into live retrieval.

Export should preserve source, scope, timestamp, and version metadata so the customer or another system can reconstruct the memory graph. A JSON file that loses scope is not a portable security boundary.

What changes at scale: noisy neighbors, retention, and billing?

Large tenants can dominate indexing, extraction, and retrieval capacity even when their data is isolated. Measure p95 latency and queue depth by tenant, apply fair-use rate limits, and keep heavy ingestion away from interactive reads.

Retention should be configurable at the tenant or data-class level without weakening deletion. Billing should map to a unit the customer can forecast, such as stored memories or writes, while the provider keeps internal capacity controls separate from the security boundary.

• Separate interactive retrieval from large ingestion jobs.
• Alert on cross-scope access attempts and repeated authorization failures.
• Report storage, write, retrieval, and deletion metrics by tenant.
• Test quotas and throttles for one tenant under another tenant’s load.
• Keep audit history available after a memory is superseded or deleted.

How does AI Memory support multi-tenant memory?

AI Memory carries user, agent, session, and tenant scopes on the memory contract and filters at read time. The Scale plan describes tenant isolation, audit history, a bring-your-own Postgres and vector store path, and a self-host option with the same API.

Those capabilities reduce the amount of retrieval infrastructure a product team must build, but they do not replace the application’s authorization model. The tenant ID must still be resolved correctly before the memory call.

What is the minimum multi-tenant memory architecture?

Use trusted identity resolution, mandatory tenant and user scopes, query-time filtering, an explicit correction and deletion path, tenant-aware export, audit history, and binary isolation tests. Add project, agent, and session scopes only where the product needs them.