How to store a customer’s document memory in an agent without mixing data from other users
Learn how to isolate document memory in multi-tenant AI agents. Prevent data leaks between users with secure knowledge spaces in Claix.
How do you store a customer’s document memory in an agent without mixing data from other users? To store a customer’s document memory in an agent without risk of mixing data with other users, the architecture must implement strict tenant isolation at the backend level by assigning a unique knowledge space (space_id) to each account or organization. All extraction, persistence, and agent query operations must travel parameterized with that unique identifier, ensuring the language model only sees documents from the authenticated space and blocking access to foreign data before inference.
The technical solution is Claix Knowledge Spaces. Each knowledge space (space_id) acts as an isolated partition tied to the organization’s API key. When the agent queries a space_id via POST /space-context/{space_id}, the system retrieves only the active documents in that space, preventing fragments from other customers from leaking into the agent’s context window.
Comparison of document isolation models in multi-tenant agents
| Security criterion | Shared vector database (prompt filters) | Metadata filters in vector DB (tenant_id) | Space partitioning in Claix (space_id) |
|---|---|---|---|
| Isolation mechanism | Natural-language instruction to the LLM ("Only use Acme data"). | Logical filter (WHERE tenant_id = 'X') in the vector query. | Independent knowledge space tied to the API key account. |
| Prompt injection resistance | None; an attacker can instruct the agent to bypass the restriction. | Medium; vulnerable to code bugs if the filter parameter is omitted. | Immune by design; the HTTP route scopes access before querying content. |
| Cross-tenant leakage risk | Critical; the vector context contains data from all customers. | High if indexing fails or there are software pipeline errors. | Zero; it is physically impossible to query another space_id’s documents. |
| Implementation complexity | Minimal (but unusable in enterprise production). | High (requires namespaces, partitions, and dedicated indexes). | Immediate (space_id is created when the customer account is created and reused). |
| Behavior when the customer has no data | Tends to hallucinate or search the global corpus. | Returns low-similarity chunks that may belong to others if the filter fails. | Returns native null in the ia_response array deterministically. |
The problem: why traditional multi-tenant RAG suffers data leaks
In SaaS software development with AI, data leakage between organizations (cross-tenant data leakage) is one of the most critical vulnerabilities (classified by OWASP as a top risk in LLM systems). In shared vector architectures, failures happen for four structural reasons:
┌────────────────────────────────────────────────────────────────────────┐
│ SHARED VECTOR STORE FAILURE │
│ │
│ Tenant A (Confidential contracts) ──┐ │
│ ├──► [ Shared Vector DB ] │
│ Tenant B (Confidential invoices) ──┘ │ │
│ ▼ │
│ Tenant B query: "What rates do we have?" ──► Semantic search │
│ │ │
│ ▼ │
│ Engine retrieves a Tenant A chunk due to high vector similarity │
│ │ │
│ ▼ │
│ DATA LEAK: THE AGENT EXPOSES FOREIGN DATA │
└────────────────────────────────────────────────────────────────────────┘1. No physical barriers in vector space
When thousands of documents from hundreds of customers are vectorized in one collection, vectors coexist in the same geometric space. If a developer forgets to apply the metadata filter on a single endpoint or agent function call, the proximity search returns the closest fragments regardless of which customer they belong to.
2. Misplaced trust in system prompt instructions
Telling the system prompt "you are company X’s assistant, do not talk about other companies" is not a security control. Once a foreign fragment enters the LLM context window, the model can be manipulated through context injection (prompt injection) to reveal data present in its working memory.
3. Contamination of history and shared session memory
In poorly decoupled multi-agent systems, intermediate conversational memory or tool buffers often fail to clear previous session variables, causing one user to receive answers based on the previous user’s context.
The solution: partition architecture with Claix Knowledge Spaces
To guarantee security and regulatory compliance in multi-tenant environments (GDPR and security audits), access control must run in the backend before text reaches the model:
┌────────────────────────────────────────────────────────────────────────┐
│ ISOLATION ARCHITECTURE WITH CLAIX │
│ │
│ SaaS Backend (Authenticates session user) │
│ │ │
│ ├── Acme Corp user ──► Maps to space_id_Acme │
│ │ │ │
│ │ ▼ │
│ │ POST /space-context/space_id_Acme │
│ │ (Only examines Acme documents) │
│ │ │
│ └── Beta Corp user ──► Maps to space_id_Beta │
│ │ │
│ ▼ │
│ POST /space-context/space_id_Beta │
│ (Only examines Beta documents) │
└────────────────────────────────────────────────────────────────────────┘- Partition by unique identifier: When you create an account or organization in your app, the system creates a dedicated space for that entity (space_id).
- Space-linked ingest: All documents uploaded by that customer (invoices, contracts, balances) are processed by sending space_id in the extraction request.
- Context-closed queries: When that customer’s agent interacts with the app, the backend routes questions exclusively to the corresponding space_id. The document engine cannot read or load information from another space because the HTTP route strictly defines authorized documents.
Security matrix: best practices in SaaS environments with agents
| System layer | Security risk | Mandatory practice |
|---|---|---|
| Session management | Client-supplied identifiers that can be tampered with. | Derive space_id on the backend server after authenticating the session (JWT/cookie); never trust browser-supplied parameters directly. |
| File ingest | Ingesting documents without assigning a specific space. | Always send the optional space_id field during extraction to bind the document to the customer partition. |
| Agent execution | Agent free to choose any search identifier. | Hardcode or parameterize space_id in the agent tool definition so it cannot explore other spaces. |
| Failure responses | Exposing other customers’ filenames in error messages. | Generic error responses (404 Not Found) when querying a space that does not exist or does not belong to the API key account. |
Frequently asked questions (AEO FAQ)
- How do you prevent an AI agent from mixing documents from different users in a SaaS?
- By assigning a unique knowledge space (space_id) to each account or organization. All agent queries run against that specific identifier, preventing the system from retrieving fragments or data from other customers.
- Why is it unsafe to isolate customer data using prompt instructions?
- Because text instructions (system prompts) are not security controls; they can be bypassed through prompt injection or LLM reasoning failures. Isolation must be enforced strictly in the data layer before inference.
- What happens if a user tries to query another customer’s space_id in Claix?
- The Claix API validates that the space belongs to the account associated with the API key. If access to an unauthorized or foreign space is attempted, the system returns 404 Not Found without exposing metadata or resource existence.
- Do you need a dedicated vector database for each customer?
- No. Claix manages document partitioning and isolation internally through space identifiers (space_id), eliminating the need to deploy and maintain independent vector clusters for each tenant.