Shared Agent Memory Can Hand One Team's Restricted Data to Another
1A Cached Answer Can Carry Data Its Next Reader Was Never Given
On October 5, 2026, two researchers posted a paper on the shared memory of enterprise AI agents, a store where one agent saves a result, such as a customer segment, so other agents can reuse it. The authors say common agent-memory systems apply access control by a saved result's content, its owner and the requester's role, and do not check how the result was computed from columns, the fields of a database table. In the paper's example, a Finance agent combines an income column with a transactions table and saves a high-value customer segment. The segment holds no income figure and no sensitivity tag, yet it was built from income, so Marketing's agent, whose role never covered income, can receive it.
The derivation path quietly violated column-level access policy, and none of the content-gated safeguards common in current memory-sharing systems ... would catch it, because the violation is invisible in the stored value and shows up only in how the value was computed.
Sangaraju and Vissa, Lineage-Aware Memory Governance
The authors' fix attaches to every saved result a record of each table and column behind it, which they call lineage, and serves the result only if the requester may see every sensitive column in it. A paper covered in August made a related argument, that agents can combine permitted actions into a prohibited outcome. In the authors' simulated workloads, a baseline memory that checked only content showed a leak rate of 18.8% on a five-table test database and 25.5% on TPC-H, a standard database benchmark. A leak here is a saved result built from a sensitive column that reaches a department not allowed to run the query. The authors state these rates "are properties of our workload mixes, not universal base rates". The lineage check cut the share of requests answered from memory from 95.8% to about 82%, roughly 13 extra query runs per 100 requests.
2The Zero Leak Rate Is a Proof That Rests on Complete Lineage
The authors' proof, Theorem 1, holds only if lineage recording is complete.
the lineage-aware system's 0% leak rate is a policy guarantee from Theorem 1, not something we discovered empirically.
Sangaraju and Vissa, Lineage-Aware Memory Governance
When the simulated agents reported half of the columns they touched, the leak rate was still 16.3% on the first schema and 10.3% on the second. It measured zero at 75% reporting on the first and at 90% on the second, and the authors recommend 90% as a minimum. In a nine-request test on the Northwind sample database, with some scripted queries, a parser that reads each SQL query recorded the columns, so the agent reported nothing itself, and no sensitive column leaked. The authors say the parser can miss columns hidden behind database views, stored procedures and nested aliases, and they call the test a nine-request proof of concept. They name the gap they see as most important for production use: a derived value that encodes sensitive information without naming its source column.
Source: Venkata Sangaraju and Sudhir Vissa, Lineage-Aware Memory Governance: A Derivation-Gated Framework for Privacy-Preserving Column-Level Access Control in Enterprise AI Agents, arXiv:2610.07258, October 5, 2026.