TL;DR. Multiple agents sharing one memory store turns a cache into a multi-user data system, and the common defense, a policy filter after retrieval, authorizes the wrong unit. Memory systems constantly derive new records from old ones: a summary computed from restricted memories is a fresh record the filter has never heard of, and a revoked source leaves its derivatives behind. Two August 2026 releases bracket the argument. Tencent Cloud's TencentDB Agent Memory 2.0 shipped team memory with private-by-default ACLs on August 3, and the MAP-Graph paper argued on August 11 that authorization has to be intrinsic to the memory graph, so restrictions propagate through derivation. Databases ran this exact argument twice: application-side filtering lost to row-level security, and RLS itself had to be patched (PostgreSQL 15's security_invoker views) because derived objects leaked around it. Shared agent memory is speed-running both lessons.
Can multiple AI agents safely share one memory store? The question stopped being hypothetical this year. Agent memory spent two years as per-agent state: one assistant, one user, one growing store of extracted facts. Now Mem0 ships an organizational memory layer, Letta lets multiple agents work from shared memory blocks, and on August 3, 2026, Tencent Cloud published the stable 2.0.0 release of TencentDB Agent Memory, an MIT-licensed hub built explicitly for the team case: your agent learns something, my agent reuses it. The moment that happens, a memory store stops being a cache and becomes a multi-user data system, and it inherits the oldest question multi-user data systems have: who is allowed to read what, and who decides.
Memory became team infrastructure, and permissions arrived with it
Tencent's release is worth reading as a design document, because it is the clearest statement yet of what "shared agent memory" means in product form. The hub turns conversations, documents, and code into four reusable asset types: Chat Memory (preferences, facts, and decisions layered from raw conversation up to personas), Skill (extracted expertise with versions and validation rules), Wiki (structured documentation with link graphs), and CodeGraph (indexed symbols and call relationships). Assets are shared across agents and frameworks, with integrations for Claude Code, CodeBuddy, OpenClaw, and Hermes.
The part that matters for this argument is the governance layer. Assets are private by default, and sharing is an explicit act. Visibility has three tiers: private (owner only), team (all members), and restricted, which takes precise ACLs scoped to users, roles, and individual agents. Ownership is tracked per asset, with two layers of admin roles above it. That is a real permission model, not a disclaimer, and shipping it as the headline feature of a memory product tells you where the category's pressure is coming from: teams will not pool what their agents learn until someone answers who gets to recall it.
So the shipped state of the art in August 2026 is ACLs on memory assets. The question is whether that model holds, and there is good reason to think it is a waypoint rather than the destination.
The bolt-on model authorizes items. Memory is not made of independent items.
The common architecture for agent memory today is a store (usually a vector index, sometimes a graph), a top-k retrieval step, and, in security-conscious deployments, a policy check that filters what retrieval returned before it enters the agent's context. Access control, in other words, is a layer wrapped around a store that has no native notion of it. This works exactly as long as every memory is an independent item whose sensitivity is fully described by its own labels.
Memory systems violate that assumption by design. Their core loop is derivation: raw turns are summarized into facts, facts are consolidated into personas, episodes are distilled into skills. Every one of those operations creates a new record whose content came from old records. The new record gets its own labels, or none. A summary computed over ten memories, two of them restricted, arrives unrestricted: a fresh row the filter has never heard of. The filter checks the artifact in front of it. Nothing checks its ancestry.
Revocation fails the same way. Sharing in these systems is an action you can undo: Tencent's model, correctly, makes unsharing possible. But unsharing a source does nothing to what was already derived from it while it was shared. Without a recorded link from derivative back to source, revocation means "stop serving this record," not "stop serving what this record taught everyone." Any engineer who has tried to un-grant access to data that was already copied into a downstream table knows this shape.
And the write path is its own exposure. MemSecBench, a benchmark posted in late July that traces memory poisoning across persistence, consequence, and repair, reports that malicious content written into long-term memory persisted in 84.2 percent of attack cases overall across its 24-configuration matrix of agent harnesses, memory backends, and LLMs, with large variation between configurations, and that recalled poison went on to shape real actions. Repair, in a store with no lineage, means hunting for every record the poison touched. Tencent's own security team supplied the output-side counterpart a week earlier: their Memory Heist research showed an agent tricked into exfiltrating its stored memory character-by-character through URL paths, invisible to monitoring that watches API calls. A store shared across a team concentrates all of this: more writers who can poison, more readers to leak to, more derivation in between.
A filter authorizes items. A provenance graph authorizes ancestry.
The research answer: put the policy inside the graph
MAP-Graph, posted to arXiv on August 11, treats this as the defining problem of shared memory rather than a hardening detail. Its premise, quoted from the abstract: relevant evidence may not be admissible for a particular agent or action, because "restrictions can propagate through derivations and conceal private, poisoned, untrusted, or revoked sources."
The design represents agents, sources, memories, claims, and actions as a typed graph. Instead of running a similarity search and filtering afterward, retrieval traces each candidate's ancestry and excludes permission-ineligible records during traversal, then reranks what survives by semantic similarity and trust accumulated along the provenance path. Before an action executes, a risk-sensitive gate evaluates it, and the lineage that fed the action is retained for audit. Authorization, provenance, and audit are one structure, not three features.
The caveats are real. This is one paper, days old, and its evaluation numbers could not be independently mirrored here. Nobody has published what ancestry-tracing retrieval costs at production scale, and multiplicative path trust is a design choice other groups will contest. What the paper contributes is less a settled system than the correct problem statement: in a memory system, authorization attaches to lineage, and any design that authorizes records one at a time has picked the wrong unit.
Databases ran this argument twice. Both endings are instructive.
If the shape of this debate feels familiar, it should. It is the database world's authorization argument, replayed on a new substrate, and databases produced two lessons the memory vendors can inherit for free.
The first: enforcement bolted onto the read path loses. For years, multi-tenant applications enforced data access with WHERE clauses in application code. Every query path had to remember the clause; one forgotten path was a breach. PostgreSQL's answer, row-level security, moved the policy into the table itself: a policy attached to the data applies no matter which code path asks. The industry consensus followed, slowly, because the argument is structural. A check that every caller must remember is a check that will eventually be forgotten; a check the store itself enforces cannot be routed around. Retrieval-time memory filters are WHERE clauses in application code, with an LLM as the application.
The second lesson is sharper and less quoted: even row-level security did not survive derivation. RLS answers who may read a row. It does not answer who may read what was computed from a row. PostgreSQL views historically executed with the privileges of the view's owner, not the reader, so a view built over an RLS-protected table could serve restricted rows to anyone allowed to read the view. PostgreSQL 15 added security_invoker views precisely to close that gap, a decade and a half into RLS's lifetime. Derived objects leaking around source policies predates agent memory by decades. It is the oldest unsolved edge of data authorization, and agent memory is the first system where derivation is the main loop rather than the edge case.
That is the standard to hold shared memory products to. Asset-level ACLs, Tencent's model, correspond to table grants: necessary, shipped, and blind to derivation. Provenance-aware authorization, MAP-Graph's model, corresponds to policy plus lineage fused into the read path. The distance between those two is the distance the category has to cover.
What to ask before your agents share a memory store
For a team evaluating shared memory this year, the failure modes above convert directly into evaluation questions.
- What is the default visibility of a new memory? Private-by-default with explicit sharing is the defensible answer, and it is the one Tencent chose.
- When a memory is derived from others, what does it inherit? If the honest answer is "nothing," every summarization step is a laundering step for restricted content.
- What does revocation propagate to? Unsharing a source should at minimum flag, and ideally retract, its derivatives. That requires lineage to exist at write time; it cannot be reconstructed later.
- Is the write path treated as untrusted? Anything an agent read from the outside world can end up written into team memory. We made the same argument about tool metadata in the MCP cache-poisoning disclosures: content that arrives with a system's authority attached is exactly the content to distrust.
- Can you audit what was recalled into which action? When a bad action happens, the question is not only what the agent did but what it remembered that led there. Without recall lineage, that question has no answer.
- Does the store know who is asking? A shared memory serving five agents through one service account has the same problem Postgres has serving five agents through one role: the permission system below the boundary cannot distinguish principals the layer above collapsed.
None of this says asset-level ACLs are worthless, or that every team needs a provenance graph this quarter. A single-team deployment with trusted members and no restricted assets gets real value from Tencent's model as shipped. The questions become load-bearing at the boundaries: across teams, across customers, or anywhere a memory store contains things some principals must never see. Those are also exactly the deployments where shared memory pays the most, which is why the pressure on this design will not relax.
The wider lesson holds beyond memory. Memory personalizes an agent; context grounds it in your data systems, and both layers are converging on the same architectural conclusion from different directions: meaning and permissions have to travel together, attached to the data, not enforced by whoever happens to be reading. Agent memory is learning it through poisoning papers and exfiltration demos. Databases learned it through two decades of leaked WHERE clauses and one patched view mechanism. The systems that skip the relearning will be the ones that copied the ending.
Where Datapace fits
Datapace is building the context layer between your databases and your AI: resolved meaning validated by the people who own the data, the workload evidence beside it (cost, performance, usage and freshness, lineage), and a policy gate over what an agent may do and access, served over MCP. The premise is the one August 2026's memory research arrived at independently: a policy bolted on after retrieval fails on derived data, so what an agent may know and do has to be part of how the layer itself is structured. If you are deciding where memory ends and context begins in your stack, start with memory layer vs context layer, or book a call.
Sources
- TencentDB Agent Memory repository and 2.0 documentation, TencentCloud on GitHub, 2.0.0 released August 3, 2026.
- MarkTechPost, "Tencent Cloud Open-Sources TencentDB Agent Memory v2.0: A Team-Level Memory Hub for AI Coding Agents", August 7, 2026.
- MAP-Graph: Provenance-Aware Shared Memory for Multi-Agent Workflows, arXiv, posted August 11, 2026.
- MemSecBench: Tracking Agent Memory Poisoning from Persistence to Consequence and Repair, arXiv, July 2026.
- Tencent Zhuque Lab, "Why AI Agent's Memory Becomes Attacker's Data Goldmine (Memory Heist)", August 6, 2026.
- PostgreSQL documentation: Row Security Policies.
- PostgreSQL documentation: CREATE VIEW (security_invoker).