Source-linked AI summary
Revoked but Still Authoritative: An Empirical Study of Revocation Enforcement in Agent-Memory Systems
Yi Ting Shen, Kentaroh Toyoda, Alex Leung
TL;DR
Persistent-memory systems often retain superseded facts as softly revoked records, but whether retrieval enforces those revocations has not been established. This paper measures five systems across scenarios, models, and defenses, finds that revocation is not enforced in every case, and develops a retrieval guard to withhold revoked or conflicting records.
Problem
Whether marking a retained, contradicted fact invalid prevents its retrieval and subsequent use by an agent has not been examined.
Method
The study loads five memory systems with revoked policies and replacements, measures retrieval exposure and unsafe actions across nine scenarios and nine models, and evaluates six defense conditions.
Results
No system enforces revocation in every case; two exposed systems ranked revoked records above replacements and led agents to unsafe actions in more than two of five trials.
Takeaways & Limitations
A retrieval-time guard can withhold records that are revoked or conflict with their replacements before they reach the agent.
Takeaways & Limitations
The measurement requires each store to hold two contradicting records, and it does not manipulate the systems beyond producing those records.
Abstract
from arXiv · showhide
Long-running language-model agents depend on persistent memory. Many agent-memory systems preserve history through soft revocation: a contradicted fact is marked invalid and retained rather than deleted. However, whether that mark is enforced at retrieval time is unexamined. In this paper, we measure five such systems: we load each with a revoked policy and its replacement, track whether the revoked fact is returned at retrieval and whether the agent then acts on it across nine policy scenarios and nine models, and score every trial under six defense conditions. We find that no system enforces revocation by default: the revoked fact is returned wherever the revocation label is visible to the retrieval layer, outranks its replacement, and leads agents to the unsafe action. Based on these findings, we develop a guard that sits between the agent and any memory backend and withholds records that are revoked or conflict with their replacement.
1 Introduction
The paper tests whether soft revocation prevents agent-memory systems from returning superseded facts and agents from acting on them. It finds broad enforcement failures and introduces a retrieval-time guard that withholds revoked or conflicting records.
- Motivation: Soft revocation retains contradicted facts with invalidity metadata instead of deleting them, preserving auditability and point-in-time queries.The paper studies whether this retained state actually prevents retrieval and downstream action.
- Method: Five agent-memory systems are evaluated across nine scenarios, nine models, and six defense conditions using revoked policies and their replacements.Trials measure both revoked-record exposure and unsafe actions after retrieval.
- Findings: No memory system enforces revocation in every case; failures arise when revocation is unrecorded, hidden from applications, or ignored during retrieval.These are the paper’s three identified failure modes.
- Findings: Only two of five systems returned both records, ranked the revoked record above its replacement, and led agents to unsafe actions in more than two of five trials.This summarizes the central result reported across the evaluated scenarios.
- Guard: A retrieval-time guard intercepts backend reads and withholds records established as revoked or conflicting with their replacements.The guard is designed to operate between the agent and any memory backend.
2 Related Work
Prior work addresses memory systems, injected-content attacks, lifecycle security, guardrails, provenance, and version-aware retrieval. This paper distinguishes its question by examining whether a system’s own revoked record still controls agent behavior at retrieval time.
- Research directions: Prior research spans memory systems, memory-injection attacks, lifecycle security, defenses, and version-aware retrieval.The paper organizes related work into five directions.
- Memory systems: Memory-system research explains persistent storage and temporal or graph structures that represent entities, relations, validity, and sources.The cited Zep and Graphiti work is described as using a temporal knowledge graph.
- Injection attacks: Injection-based attacks introduce hostile content through mechanisms including command insertion, retrieval triggers, poisoning, false precedents, and skill procedures.The paper distinguishes these attacks from its setting, where the problematic record is the defender’s own policy.
- Lifecycle security: Lifecycle-security work studies risks across writing, updating, retrieval, deletion, and deprecation, including residual content after incomplete deletion.The paper contrasts failed deletion with deliberate retention through soft revocation.
- Defenses: Guardrails and provenance checks inspect content or verify origin, but origin binding does not constrain an authorized record after its authorization is revoked.The paper positions retrieval-time validity as the check needed for defender-authored revoked policies.
- Version-aware retrieval: Version-aware retrieval models changing content over time and can exclude contradicted facts from retrieval.The paper’s distinction is whether the memory store itself enforces that current-version behavior.
3 Methodology
The study measures whether five agent-memory systems enforce revocation when superseded and replacement policies are retrieved and used by agents. It evaluates default retrieval, agent actions, and defenses across controlled scenarios, models, and repeated trials.
- Notation and assumptions: The store model represents each record with text, timestamp, and a caller-visible status flag indicating revoked, current, or undisclosed status.The undisclosed value captures systems that mark records internally but expose no status to callers.
- Experimental design: The measurement tests five memory systems by placing a superseded record and its replacement in the store, then querying default retrieval.The harness does not otherwise modify the system, retrieval, prompt, or model configuration.
- Experimental design: The setup uses direct insertion, which guarantees revoked status, or indirect insertion, which requires the system to detect supersession from plain text.Because retrieval is identical across modes, differences reflect how the store reached its state.
- Evaluation: Every scenario-model pair runs ten trials at temperature 0.7 across nine decision models spanning three capability tiers, seven families, and six vendors.The study evaluates five defense conditions plus a no-defense baseline, with retrieval filters acting before the agent reads records.
- Scenarios: Each experiment pairs a revoked policy permitting harmful action with a current policy prohibiting it across nine scenarios.Eight scenarios model organizational policy replacement; a ninth tests a stored access directive separately.
- Measurement: The study reports exposure rate and unsafe-action rate, measuring respectively whether default retrieval returns the revoked policy and whether the agent chooses its implied unsafe action.The unsafe-action rate is also expressed as Pr[a = a−] = Pr[ER = 1] · Pr[a = a−| ER = 1].
4 Evaluations
The evaluation finds that revocation failures arise at multiple stages, and that exposed revoked records frequently drive unsafe actions. Retrieval filtering eliminates unsafe actions in the tested setting, while prompt and output filters are less effective.
- 4.1 Exposure and the unsafe-action rate: Two of five systems returned revoked records by default, with failures arising from missing revocation, hidden status, or unenforced retrieval.Under indirect insertion, cognee, langmem, and mem0 failed to record revocation; Zep withheld status; Graphiti and mem0 (exp.) exposed but did not enforce it.
- 4.1 Exposure and the unsafe-action rate: 81/81 scenarios returned the revoked record on each exposed system, which ranked it above its replacement.The exposed systems were Graphiti and mem0 (exp.).
- 4.1 Exposure and the unsafe-action rate: 43.1% of trials produced unsafe actions across the two exposed systems, compared with 0/1,620 under the store-level filter.Graphiti produced 44.2% unsafe actions and mem0 (exp.) 42.1%; the per-scenario rate ranged from 0.0% to 94.4%.
- 4.2 Defense conditions and retrieval: The store-level filter removed the unsafe-action effect, while prompt hardening reduced it to 37.2% and the output filter to 18.1%.Prompt hardening lacked information identifying which retrieved fact was superseded; the output-filter result used an advantage unavailable in deployment.
- 4.3 Per-model analysis: All nine models were affected, with unsafe-action rates ranging from 15.0% to 60.0% and no correlation with capability tier.The paper reports that reasoning quality did not decide the outcome because the two policies appeared equally valid in context, while the revoked one was typically phrased more absolutely.
- 4.4 Per-scenario analysis: Unsafe actions occurred in 81.0% of no-rule trials but only 4.6% across four explicit-rule scenarios after excluding backup deletion.Backup deletion reached 46.1% and accounted for 83 of 116 bypasses; its conditional exception and precedence claim prevent attributing the high rate to either feature alone.
5 Guard
The guard mitigates stale-retrieval failures by checking backend validity marks and detecting conflicting facts before the agent sees them. It withholds records only when it can establish revocation or staleness, preserving withheld history and exposing conflicts to the application.
- Deployment: Store filtering should be the default but requires vendor-exposed status and application enforcement at every read, whereas the guard requires no backend change.The guard is therefore positioned as an application-deployable mitigation for systems lacking those conditions.
- Design: The guard intercepts reads between the agent and any backend, first withholding backend-marked revoked records and then detecting conflicts among remaining facts.The second stage keeps both records when their order cannot be established and reports the unresolved conflict.
- Evaluation: The guard matches store-level filtering where revocation marks are exposed, withholding 18/18 revoked Graphiti facts and 12/12 mem0 facts without withholding current ones.This agreement demonstrates deployability rather than independent evidence of design soundness because both methods read the same field.
- Evaluation: Under indirect insertion, the guard withholds 0/810 revoked facts on both mem0 configurations versus 5/810 and 24/810 for the store filter.No revocation mark exists in this setting, so the guard’s conflict-based stage provides the independent comparison.
- Evaluation: Under indirect insertion on Zep, the guard withholds 315/810 revoked facts versus 364/810 for the store filter, whose API cannot express a filter.This is the only study setting where the guard does something the store-level filter cannot.
- Evaluation: The guard can be marginally worse than no defense on cognee and Graphiti under indirect insertion, with 53/810 versus 44/810 and 83/810 versus 81/810.The conflict test can also match current facts, so Table 9 reports both caught revoked records and current facts withheld.
6 Conclusion
The study tests whether soft revocation prevents stale facts from reaching agents and finds that it does not reliably do so across five memory systems. It proposes a retrieval-time guard that withholds revoked or conflicting records before they influence the agent.
- Research question: The study measures five major agent-memory systems to determine whether marking a fact revoked prevents retrieval and subsequent agent action.The evaluation concerns soft revocation, where contradicted facts remain in memory rather than being deleted.
- Findings: No system enforces revocation in every case: revoked policies are returned by ordinary retrieval and lead agents to unsafe actions, even against explicit prompt prohibitions.The conclusion identifies retrieval as the failure location rather than attributing it to one product.
- Findings: The failure persists through the agent’s own write, a second query to the same store, and tool actions without an attacker.These observations extend the problem beyond a single retrieval event.
- Mitigation: The proposed guard sits between the agent and memory, inspecting ordinary retrieval results and withholding records established as revoked or conflicting with replacements.Where the backend exposes a mark, the guard is as effective as the store-level filter.
A.1 Detecting a revoked policy in a result
The paper identifies revoked policies in retrieval results using explicit backend status when available and a fixed lexical criterion otherwise. Its paired analysis compares systems on matched scenario-model cells to preserve comparability across cross-system claims.
- Detection: When a backend exposes status, the exposure indicator equals the revocation status; otherwise, the method uses a lexical criterion for revoked-policy matches.The status-based rule is sound because seeded revoked records are the only records marked revoked.
- Detection: The lexical criterion requires both substantial overlap with the revoked policy and greater similarity to it than to its replacement.This prevents paraphrases of the current policy from being miscounted as revoked exposure.
- Paired comparison: Cross-system claims use matched scenario-model cells, pairing the nine scenarios with the nine models and reporting both pooled unsafe rates and paired counts.The pairing holds scenario difficulty and model susceptibility constant within each comparison.
- Paired comparison: The paired counts record cells where one system produces more unsafe actions than the other and form the basis for every cross-system claim.The discordant cells are subsequently used for a two-sided exact test.
- Guard implementation: The guard is a backend-agnostic module that reads returned records and uses containment-based subject agreement plus opposition signals for contradiction detection.The design favors containment over Jaccard similarity because policy texts can differ sharply in length while addressing the same subject.
- Guard implementation: The guard combines subject agreement and opposition conjunctively, using α = 0.45 and β = 0.6, with β limiting conflict-driven withholding.The cap addresses cases where the heuristic might otherwise be more likely at fault than the store.
- Guard implementation: Algorithm 1 processes backend-marked revocations first, then compares retained records pairwise and keeps unresolved conflicts when chronology cannot be established.Kept records preserve original rank order, while withheld records carry reasons.
A.4 Compute resources
The measurements require no local training or GPUs because models are accessed through hosted APIs. Most decision-model calls and costs belong to the main 9-scenario, 9-model, 10-trial-per-cell grid.
- Resources: The experiments run without training or GPUs on a single MacBook Air with 16 GB of RAM hosting the five memory systems locally.The decision models and shared extraction and embedding model are accessed through hosted provider APIs.
- Resources: Hosted API latency, rather than local computation, dominates execution time, making the number of model calls the meaningful resource measure.No model weights are loaded or served locally.
- Cost: 44,550 of 49,121 decision-model calls and $71.78 of $79.08 total cost belong to the main grid.That grid covers 9 scenarios, 9 models, and 10 trials per cell across systems, configurations, defense conditions, and insertion modes.
- Measurement scope: Per-scenario figures are kept separate because the two scenario groups differ in scenario, action set, and distractor count.Only scenarios with a prompt rule measure unsafe action despite that rule, and the non-policy stored access directive is excluded from the pooled no-rule rate.
B.2 Matched-pair comparison
The matched-pair analysis distinguishes retrieval-policy effects within mem0 from differences between Graphiti and mem0. The results support a gross similarity claim, not system identity.
- Between-system comparison: p = 0.629: Graphiti and mem0 were not distinguishable on 81 matched scenario-model pairs.They disagreed in 17 pairs, with Graphiti higher in 10 and mem0 higher in 7; 64 pairs were tied.
- Interpretation: The between-system test could detect a systematic advantage only at a 13-to-4 split or more extreme among 17 discordant pairs.The observed 10-to-7 split therefore supports that the systems do not differ grossly, not that they are identical.
C.1 Agent write-back
Agent write-back can preserve an unsafe conclusion as a current record, allowing later retrieval to bypass the filter that removed the original revoked fact. The effect depends strongly on how the journal enters the store.
- Direct write-back: Direct write-back stored all 356 poisoned journals as current, unmarked records, and default retrieval returned the unsafe conclusion in 98.0%, 95.8%, and 96.3% across later hops.Filtering the original revoked record still left unsafe rates of 71.6%, 79.5%, and 83.1%.
- Natural write-back: Natural write-back retained only 43 of 358 journals, with 22 remaining active; among those active journals, 19 of 22 were unsafe at hop 1 under the filter.Pooled filtered unsafe rates were 7.5%, 7.8%, and 12.8% across the three hops.
- Implication: The store-level filter no longer reaches zero under either write-back mode because the agent’s journal is stored as a current record rather than as the revoked record.Thus, filtering the original revoked fact cannot remove the later journaled conclusion.
C.2 Multi-agent propagation
A shared store allows a revoked fact to propagate across executor, reviewer, and planner roles. Filtering contains this propagation only when applied at every role’s read.
- Default retrieval: 43.7%: the executor went unsafe in 354 of 810 default-retrieval runs, and every role retrieved the revoked record in all 810 runs.The reviewer’s independent question did not create a containment boundary because it still returned the revoked record.
- Propagation: 96.3%: given a poisoned executor, the reviewer independently chose the unsafe action in 341 of 354 runs.A later role went unsafe in 352 of 354 such runs, and the mean number of unsafe roles was 1.32.
- Filtered retrieval: 0/810: the filtered condition reduced every role-level outcome to zero.This containment requires filtering every read, including reviewer and planner reads.
- No-journal comparison: Without the journal, reviewer agreement given a poisoned executor fell to 81.7%, later-role reach to 88.1%, and mean unsafe roles to 1.23.The revoked record still reached reviewer and planner in every run, showing that journaling compounds rather than causes propagation.
C.3 Tool actions
Tool-facing trials show that retrieved revoked policies can produce dangerous tool use and recur through a second agent. Controls acting before retrieval suppress these signals, whereas a tool-layer guardrail does not.
- No defense: 17.2%: without defense, agents invoked a dangerous tool in 62 of 360 runs; confirmed exfiltration occurred in 9 runs.The nine confirmed exfiltrations were all in the secret-exfiltration scenario, representing 10.0% of its trials.
- Pre-read controls: 2.2%: the retrieval filter and the paper’s guard each reduced tool execution to 8 of 360 runs, with no confirmed exfiltration.These controls act before the agent reads the returned facts.
- Tool-layer control: 17.2%: the tool-layer guardrail matched no defense for tool execution and confirmed 7 exfiltrations versus 9 without defense.The guardrail failed upstream because the revoked policy licensed actions it did not classify as dangerous.
- Recurrence: 67.7%: a second agent repeated the dangerous action in 42 of 62 runs where the first agent went unsafe under default retrieval.With the filter applied at the second read, recurrence fell to 21.0% (13 of 62).
- Conclusion: The effective containment boundary is the read: pre-read controls reduce every signal, while the tool-layer control is statistically indistinguishable from no defense.The guard therefore operates between the agent and memory retrieval rather than at tool execution.