AI Agent Memory Lineage Can Block Hidden Data Leaks Across Teams

A cached metric can carry a hidden data trail

A number can look harmless and still expose information drawn from a restricted source. When an AI agent stores a derived result in shared memory, access checks may continue to protect the underlying records while leaving the cached answer available to other agents. The gap is easy to miss because the answer can appear detached from the data that produced it.

Consider a Finance agent joining transactions with customer_pii, which includes an income column, to calculate a 90-day churn_rate. The query returns 0.114, a single float with no names, account numbers, or income figures. The agent caches it so future requests can skip the query. From a user’s perspective, that may look like a low-risk convenience: one compact metric, ready to reuse.

A week later, a Marketing agent requests churn_rate and receives the cached value. Marketing’s role-based access control (RBAC) rules block access to income, but the agent hasn’t queried that column. It asked for a KPI by name, and the access check on the original data doesn’t govern the stored result. The permission system may be working as designed at the table and column level; the problem is that the answer has crossed into a different store, where its origin isn’t necessarily visible.

This is more significant than it looks. A derived metric doesn’t have to reveal a person’s exact income to create a boundary problem: it can still reflect calculations that depended on data a recipient wasn’t authorized to inspect. Whether that creates a meaningful disclosure depends on the metric, the surrounding information, and how it’s used. The central issue is simpler: a value’s small size and neutral label don’t tell you which inputs shaped it.

Why ordinary permission checks can miss the gap

Traditional access controls commonly evaluate a request against a resource, such as a table or column. A cached answer changes the shape of that request. The second agent may ask for a named result rather than the source fields, and the memory layer may return the stored value without repeating the original query. If the system checks only who can read the cached object, it may not check whether that agent could access every source used to calculate it.

That distinction matters in systems where agents share memory to avoid repeating work. Reuse can reduce duplicated queries and make common answers easier to retrieve, but it also separates the moment of calculation from the moment of access. A permission decision made for the first agent doesn’t automatically settle whether another agent should receive the same result later.

There’s a second complication: labels are summaries, not evidence. A cache entry called churn_rate says what the value represents, but it doesn’t necessarily record the tables, columns, joins, or filters behind it. Without that information, a retrieval gate has little basis for applying the original data rules to the cached answer.

And this is the part most people overlook: the access decision has to travel with the result. Otherwise, a system can enforce permissions correctly at query time and still expose a derived value through a separate path. Not a failure of the original query check, but a gap between that check and later reuse.

Check how the result was produced

The proposed fix is to evaluate a cached result’s derivation graph: the tables, columns, and filters involved in producing it. That gives the retrieval gate information about the source data, rather than relying on a label added to the finished value. In practical terms, the system can use that recorded lineage when deciding whether a requesting agent is allowed to receive the result.

This approach treats a cached metric as more than a standalone number. Its history becomes part of the access decision. If a calculation depended on a restricted column, the gate can account for that dependency even when the later request names only the KPI. The mechanism is targeted: it addresses the mismatch between permissions on source data and access to derived results.

Lineage also gives teams a clearer way to inspect why a result was allowed or blocked. A system that records which inputs contributed to a cached answer can make the decision easier to explain and audit. That doesn’t guarantee every dependency is captured correctly, though; the value of the check depends on the quality and completeness of the recorded graph.

Benchmark tests reduced structural cross-department leaks from 18.8%–25.5% to zero. The trade-off was roughly 13 extra query executions per 100 requests; the gate-check predicate itself cost 0.09 microseconds. Those figures suggest the check’s direct computation can be small while the broader system cost shows up in additional query work.

The result is encouraging within the tested scope, but it needs careful reading. “Zero” here describes the measured structural leaks in those benchmark tests; it doesn’t establish that every possible disclosure path disappears. Likewise, the extra executions are a concrete cost in the reported setup, not a universal forecast for every agent system. Performance will depend on how often cached answers are requested and how the surrounding query and memory layers work.

What the safeguard covers—and what it leaves open

That’s a targeted safeguard, not a complete defense. It doesn’t prevent inference attacks, a compromised memory store, or collusion. Those risks involve different failure modes: a user may infer sensitive facts from permitted outputs, an attacker may access stored values directly, or agents may combine information in ways the gate doesn’t recognize.

For teams sharing agent memory, tracking lineage can close a specific gap that ordinary data permissions leave open, with a measurable cost in query execution. If you’re working in this space, the practical question is whether your cache can explain how each result was produced and whether retrieval checks that history against the requester’s permissions. A permission boundary that stops at the original query may not extend as far as the team assumes.

There’s a trade-off to manage. More checks can constrain which results agents reuse, while fewer checks can leave derived data outside the protections applied to its inputs. The benchmark points to one way to make that decision more informed: preserve the result’s source dependencies and evaluate them when another agent asks for it. Whether that is enough depends on the threats a system needs to address, and the limits are explicit.

Shared memory makes prior work reusable. It also makes the path from source data to later answers part of the security design.