57-71% of AI agents leak data between users. Here's what to do.
Summary: A June 2026 Mem0 survey reveals that 57-71% of agent harnesses leak memory between users. This happens because most systems use keyword retrieval without user isolation. Builders must implement per-user namespaces and principal checks to prevent PII leaks and credential bleed.
Mem0's June 2026 survey of 8 major agent harnesses included Claude Code, Codex, and Bedrock AgentCore. They found a 57-71% cross-user memory contamination rate. Most of these systems rely on keyword retrieval. They lack user-scoped isolation.
If you run agents for multiple users, your memory layer is likely leaking.
Why does keyword retrieval fail across users?
Most agent runtimes use simple keyword matches to pull relevant memories into the context window. This works well for single-user assistants. It fails in multi-user environments because the retrieval layer has no concept of a principal.
When User B asks a question, a fuzzy match might pull a memory fragment written by User A. If User A stored PII or credentials, those secrets are now in User B's prompt. The agent has no way to know it just crossed a security boundary.
What are the real failure modes of memory contamination?
Memory contamination is not just a style issue. It creates three critical risks:
- PII leak: Personal data from one user appears in another's session.
- Decision contamination: A policy or preference set by User A influences the agent's actions for User B.
- Credential bleed: API keys or tokens stored in memory by an admin become accessible to a standard user.
How do you fix the agent memory layer?
To build secure multi-user agents, you need to move beyond simple keyword search. Use these four patterns:
1. Per-user namespaces. Every memory must be tagged with a unique UserID. The retrieval query must include a hard filter on that ID.
2. Recall-time principal checks. Before a retrieved memory is injected into the prompt, verify that the current session principal has read access to that specific memory object.
3. TTL and staleness handling. Memories should not live forever. Implement time-to-live (TTL) settings and session-based eviction to ensure sensitive data does not linger in the vector store.
4. Vector partitioning. Use physical or logical partitioning in your vector database to ensure that a search for one user cannot even "see" the data of another.
How does AgentGuard help secure agent memory?
Isolating memory is only half the battle. You also need to enforce scope at the action layer.
AgentGuard provides the runtime budget and scope enforcement that acts as the action-layer analogue of memory isolation. Just as you should not let an agent recall User A's data for User B, you should not let an agent spend User A's budget on User B's tasks.
By wrapping your agent in AgentGuard, you ensure that even if a memory leak occurs, the agent's ability to act on that leaked data is strictly bounded by the current session's security policy.
Top comments (0)