Pith. sign in

REVIEW 3 major objections 5 minor 14 references

Agent memory poisoning often sticks, drives later harmful actions, and is hard to repair cleanly—and different memory stacks diverge sharply on both attack success and selective repair.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

T0 review · grok-4.5

2026-07-30 11:42 UTC pith:XICVNKWU

load-bearing objection Careful lifecycle benchmark with real multi-stack numbers; judge overlap and single-run rates are real caveats, not reasons to ignore it. the 3 major comments →

arxiv 2607.27080 v1 pith:XICVNKWU submitted 2026-07-29 cs.CR cs.AI

MemSecBench: Tracking Agent Memory Poisoning from Persistence to Consequence and Repair

classification cs.CR cs.AI
keywords agent memory securitymemory poisoningLLM agentslifecycle evaluationselective repairmemory backendsWrite-Execute-Forgetbenchmark
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

MemSecBench argues that agent memory security cannot be judged by whether a model notices bad content in a single turn. Malicious instructions can be written through ordinary workflows, persist in long-term memory, be recalled later on a benign task, and produce a real external consequence—unless the agent can later remove only the bad rule while keeping needed benign memories. The authors build 310 linked task packages across realistic code/science, daily-life, and office settings and run each under a controlled Write–Execute–Forget protocol in isolated runtimes, comparing 24 exact stacks of harness, memory backend, and model. Across those configurations, malicious memory persists in most cases and the full write-to-consequence chain succeeds about half the time; among poisoned cases, selective repair succeeds only a bit more than half the time. Matched comparisons against native memory show large swings in end-to-end attack success and especially in repair quality, so memory backends matter as security factors, not interchangeable utilities.

Core claim

Under matched lifecycle evaluation, current agent memory stacks are widely susceptible: malicious semantics persist in 84.2% of cases and complete the Write–Execute chain in 50.3%; among successfully poisoned cases, 59.6% finish Execute while only 56.1% achieve selective repair. Adoption is the main attack bottleneck and benign-memory preservation is the main repair bottleneck, and no backend is uniformly safer—resistance and recovery are distinct.

What carries the argument

MemSecBench’s Write–Execute–Forget protocol with seven evidence-gated checkpoints (write acceptance, persistence, recall, adoption, externalized consequence, target repair, benign preservation), scored by deterministic checks, a judge model on admissible evidence packs, and programmatic gates under fixed harness–backend–model configurations.

Load-bearing premise

The central results rest on treating checkpoint-specific judge-model decisions plus automatic gates as faithful ground truth for whether bad content truly persisted, was adopted, caused the named consequence, and was selectively repaired.

What would settle it

Re-adjudicate the same run evidence with independent human labels or a held-out judge on the full set of checkpoints; if persistence, end-to-end attack, or selective-repair rates shift enough to erase the reported macro gaps and backend contrasts versus native memory, the lifecycle-security claims fail.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Memory safety evaluations must track the same malicious semantics from write through verified external consequence and selective repair, not only single-turn refusal or retrieval probes.
  • Product and research stacks should treat harness, memory backend, and model as a joint security surface; swapping backends can move both attack success and repair quality by large margins.
  • Defenses that only block writing or only delete target rows are incomplete if agents still adopt recalled poison or wipe required benign memory during repair.
  • Adoption-time checks and repair that preserve benign state are higher-leverage than further tightening already-high persistence and recall rates alone.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Memory backends may need explicit temporal scope, authority, and provenance fields as first-class storage—not only better embeddings—because several failure modes in the corpus are lost conditions and stale rules.
  • If selective repair remains hard, operators may need versioned or dual-store memory (quarantine vs trusted) rather than in-place edit of a single long-term store.
  • Benchmarking only native file memory understates the design space: structured notes and graph-linked stores can trade attack surface for repairability in configuration-specific ways worth ablating mechanism by mechanism.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. MemSecBench introduces a task-grounded benchmark of 310 Write–Execute–Forget cases that traces the same malicious memory semantics through persistence, verified external consequence, and selective repair across seven evidence-based checkpoints. The evaluation covers a 24-configuration matrix (two harnesses × four memory backends × three LLMs) under isolated runtimes with pinned stacks, a deterministic write check, checkpoint-specific judge-model adjudication with citation allowlists and programmatic gates, and independent Execute/Forget branches from verified post-Write snapshots. Macro results report 84.2% malicious persistence (MPSR), 50.3% end-to-end Write–Execute success (E2E-ASR), and, among successfully poisoned cases, 59.6% full Execute completion (MESR) and 56.1% selective repair (SRSR). Matched contrasts versus Native reach up to 16.1 pp (E2E-ASR) and 41.3 pp (SRSR). The authors interpret these as descriptive evidence that memory stacks differ in both attack propagation and repair, with adoption and benign-memory preservation as primary bottlenecks.

Significance. If the protocol and rates hold, this is a substantial contribution to agent memory security evaluation. Prior work typically covers only fragments of the poisoning lifecycle; MemSecBench is distinctive in coupling intended-interface writing (IW), verified external consequence (DC), full semantic chain (ST), selective repair with benign preservation (SR), and matched multi-backend comparison (MMI) in one controlled design. Strengths include reproducible isolation and pinning, independent Execute/Forget restoration from the same poisoned state, explicit E3 consequence contracts, and transparent count/denominator reporting in Table 2. The finding that no backend is uniformly safer, and that resistance and recovery are separable, is practically useful for system builders. The benchmark artifact and adjudication framework are likely to become reference infrastructure even if individual point estimates shift under re-adjudication.

major comments (3)
  1. [Appendix E; Table 2; Figure 4–5] Appendix E and Table 2: DeepSeek-V4-Pro is both the sole semantic judge for W2/E1–E3/F1–F2 and one of the three evaluated agent LLM backends. DeepSeek agent rows are therefore not fully independent of the adjudicator. Human agreement is reported only on a 500-record stratified sample (90.6–91.8% accuracy), not as a full audit or as agreement stratified by agent LLM / memory backend / checkpoint. Because the headline bottlenecks (E2 drop; F2 vs F1 gap) and the largest Native contrasts (up to 16.1 / 41.3 pp in Figure 5) are driven by these semantic verdicts, the manuscript should (i) explicitly discuss self-adjudication risk, (ii) report agreement broken down by checkpoint and by whether the agent LLM equals the judge, and (iii) if feasible, re-judge a stratified subset with a held-out model. Without this, the precise percentage-point claims are less secure than the abstract presents, even
  2. [Experiments, Eq. (1); Table 2; Findings 1–2] Eq. (1) and Table 2: MESR and SRSR condition on successful poisoning within each configuration (denominator ∑ w_k,i). Backend and LLM differences in MPSR therefore reshape the conditional populations before exploitation or repair is measured. The paper states this, but the abstract and Findings 1–4 still narrate adoption and repair bottlenecks and cross-backend gaps as if they were pure post-poisoning effects. A load-bearing clarification is needed: either report complementary unconditional rates (e.g., joint Write∧Execute and Write∧Forget over all N), or show that the main contrasts survive inverse-probability / matched-poisoning analyses, or restrict primary cross-backend claims to E2E-ASR and MPSR (which share the full denominator). As written, denominator composition can inflate or deflate apparent MESR/SRSR gaps.
  3. [Methodology, Skill-Guided Case Construction; Appendix A.2] Methodology (Skill-guided construction) and Appendix A.2: Case packages were proposed/revised with GPT-5.5, which is also an evaluated agent backend, under human gating. The manuscript correctly separates the authoring model from runtime evaluation, but does not quantify whether cases are differentially easy or hard for GPT-5.5 agents (e.g., MPSR/E2E stratified by authoring-model match, or a small human-rewritten control subset). Because the corpus is the measurement instrument, even modest authoring–evaluation coupling could bias stack rankings involving GPT-5.5. A short sensitivity check or explicit negative result on this point would secure the claim that contrasts reflect memory stacks rather than corpus–model affinity.
minor comments (5)
  1. [Abstract; Finding 1] Abstract vs body: the abstract states “59.6% complete the full Execute chain” among poisoned cases, while Finding 1 emphasizes the E2 adoption drop (76.1%→53.7%) and E2E 50.3% over all cases. Align the abstract wording with the metric definitions (MESR vs E2E-ASR) to avoid conflating conditional and unconditional rates.
  2. [Figure 5; Finding 3–4] Figure 5’s signed deltas are informative but dense; a small table of Native-matched E2E-ASR and SRSR for all 12 harness–LLM pairs would make the “largest absolute differences” claim easier to verify without visual decoding.
  3. [Related Work, Table 1] Table 1 comparison marks (✓/●/✗) are useful; briefly state the decision rule for ● (“process exercised but incompletely verified”) with one concrete example per prior system to reduce subjectivity in related-work scoring.
  4. [Appendix D; Experiments] Appendix D notes single-run evaluation and no automatic relaunch. Mention run-to-run variance (even on a small pilot subset) or confidence intervals for macro rates in the main text so readers can gauge stability of the 16.1 / 41.3 pp contrasts.
  5. [Throughout] Minor prose/spacing artifacts appear throughout (e.g., missing spaces in “Memorysystems”, “Write–Execute–Forget” line breaks). A copy-edit pass would improve readability without changing substance.

Circularity Check

0 steps flagged

No significant circularity: headline rates are empirical pass counts under a fixed protocol, not quantities forced by fitted inputs or self-definition.

full rationale

MemSecBench is an empirical systems benchmark. Its load-bearing claims are configuration-level fractions (MPSR, MESR, E2E-ASR, SRSR) computed from binary checkpoint outcomes on 310 cases × 24 configurations. Those metrics are defined as ordinary pass-rate estimators (Eq. 1) over adjudicated run records; they are not algebraic rearrangements of fitted parameters, uniqueness theorems, or renamed prior laws. Taxonomy labels are explicitly barred from checkpoint evidence and gates, so axis labels cannot manufacture Persistence/Adoption/Repair. Case authoring is human-gated and static acceptance does not count as W1–F2 success. Mild independence concerns (GPT-5.5 used in authoring while also evaluated; DeepSeek-V4-Pro as both judge and an agent backend; single-run conditional MESR/SRSR denominators) affect external validity of contrasts, not circular reduction of a claimed derivation to its inputs. No self-citation chain forces the numerical results. Per the circularity rubric this is an honest non-finding.

Axiom & Free-Parameter Ledger

3 free parameters · 5 axioms · 3 invented entities

This is an empirical systems benchmark. Load-bearing premises are protocol and measurement assumptions rather than physical laws or fitted constants. The claim rests on synthetic task packages, isolated runtime fidelity, backend adapters as part of the evaluated condition, and judge+gate adjudication as a proxy for ground truth.

free parameters (3)
  • Judge temperature / single-call judge budget = temperature 0; 120s HTTP attempt
    Semantic checkpoints use temperature 0 and one 120s judge call; these evaluation hyperparameters can move borderline verdicts even though they are not fit to maximize attack rates.
  • Backend retrieval budgets (top-k, thresholds, hybrid weights) = backend-specific; not equalized (Appendix C)
    Native/Mem0/A-MEM retrieval settings (e.g., top-6 with 0.35 threshold, k=5, embedding choices) are backend-specific and not equalized; they affect recall/adoption rates and thus comparative security claims.
  • Agent execution budgets (turns/time/tokens) = 900s; 32 turns; 8192 tokens
    Stage timeout 900s, Hermes ≤32 turns, OpenClaw ≤8192 output tokens constrain whether Execute/Forget complete and can change measured success.
axioms (5)
  • domain assumption Attacker-controlled content reaches the agent only through a supported Carrier and Write uses the intended memory interface; account/session compromise is out of scope.
    Threat Model section; defines what ‘lifecycle risk after content enters this workflow’ measures.
  • ad hoc to paper Case-specific W2 rubrics plus E3 consequence contracts correctly specify the malicious semantics and externalized harm for each scenario.
    Benchmark design: W2 rubric is the sole target-semantics specification tracked across stages.
  • ad hoc to paper A judge-model decision citing only admissible evidence identifiers, after programmatic gates, is an adequate operationalization of Persistence/Recall/Adoption/Externalization/Repair.
    Appendix E adjudication protocol; central to all non-W1 metrics.
  • domain assumption Matched comparisons that fix harness, LLM, task package, runtime, clean init, environment, and evidence protocol isolate memory-backend stack effects (including adapters/settings).
    Experimental Setup / Appendix C; authors correctly note they compare complete backend conditions, not pure storage ablations.
  • domain assumption Synthetic identities, services, and workspaces are sufficiently realistic that measured rates inform real agent deployments.
    Ethical Statement and case-construction protocol; standard external-validity assumption for security benchmarks.
invented entities (3)
  • MemSecBench lifecycle task package T=(ρ, xW, xE, xF, ℓ) with seven checkpoints (W1–F2) no independent evidence
    purpose: Unit of evaluation that links one malicious-semantics target through persistence, consequence, and selective repair.
    Core invented benchmark object; not a physical entity, but the construct all metrics depend on.
  • Target memory manifest binding W2 rubric to matched backend artifacts no independent evidence
    purpose: Shared evidentiary reference so Execute and Forget judge the same poisoned semantics after backend-specific rewriting.
    Introduced in methodology/Appendix E to keep cross-stage semantics aligned.
  • MPSR / MESR / E2E-ASR / SRSR metric suite no independent evidence
    purpose: Summarize poisoning, conditional exploitation, end-to-end attack, and selective repair.
    Paper-defined rates; interpretability depends on denominators (all cases vs poisoned-only).

pith-pipeline@v1.2.0-daily-grok45 · 32425 in / 3759 out tokens · 77820 ms · 2026-07-30T11:42:51.686372+00:00 · methodology

0 comments
read the original abstract

Memory systems allow agents to retain and reuse information from past interactions, but they can also let malicious content persist. A malicious instruction crafted by an attacker may be stored in long-term memory, recalled much later, and quietly shape a real action. Recent benchmarks increasingly examine agent memory security, yet few trace the same malicious semantics across persistence, downstream consequences, and selective repair under diverse memory-backend comparisons. To address this gap, we introduce MemSecBench, a task-grounded benchmark for the lifecycle security of agent memory systems. It contains 310 cases drawn from 48 realistic contexts across code and science, daily life, and office work. Each case follows a controlled Write--Execute--Forget protocol in an isolated runtime under an exact agent configuration, defined by an agent harness, a memory backend, and an LLM backend. Evidence-based adjudication combines a deterministic write check, checkpoint-specific judge-model evaluations, and programmatic gates across seven lifecycle checkpoints. The experimental design spans a 24-configuration matrix of two agent harnesses, four memory backends, and three LLM backends. Across all 24 configurations, malicious memory persists in 84.2% of all cases, and the full Write--Execute chain succeeds in 50.3%. Among successfully poisoned cases, 59.6% complete the full Execute chain, while 56.1% achieve selective repair.Compared with matched Native configurations, the largest absolute differences are 16.1 percentage points for end-to-end attack success and 41.3 percentage points for selective repair. These descriptive contrasts indicate that the evaluated memory system stacks differ in lifecycle security, both in the propagation of malicious memory and in selective repair after successful memory poisoning.

Figures

Figures reproduced from arXiv: 2607.27080 by Jiajun Zhou, Qi Xuan, Shanqing Yu, Wentao Fu, Xuanze Chen, Xukang Xie.

Figure 1
Figure 1. Figure 1: An example of how temporal-context loss can turn [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Memory poisoning threat model. Life, and Office Work [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Overview of MemSecBench benchmark construction and lifecycle evaluation. The left panel summarizes the appli￾cation domains, four design axes, and linked task-package structure. The center panel shows the evaluated agent-harness–LLM￾backend–memory-backend configuration and the Write–Execute/Forget workflow. The right panel shows checkpoint-specific evidence adjudication and lifecycle gates. STEP 2: establi… view at source ↗
Figure 4
Figure 4. Figure 4: Configuration-macro-average lifecycle rates. At [PITH_FULL_IMAGE:figures/full_fig_p006_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Security gains over Native under matched harness– [PITH_FULL_IMAGE:figures/full_fig_p007_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Joint composition of the 310 lifecycle task packages across four complementary benchmark design axes. [PITH_FULL_IMAGE:figures/full_fig_p011_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Configuration-wise lifecycle profiles by application domain. Rows report MPSR, MESR, E2E-ASR, and SRSR; [PITH_FULL_IMAGE:figures/full_fig_p024_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Configuration-wise lifecycle profiles by risk type. Rows report MPSR, MESR, E2E-ASR, and SRSR; columns fix the [PITH_FULL_IMAGE:figures/full_fig_p025_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Configuration-wise lifecycle profiles by carrier. Rows report MPSR, MESR, E2E-ASR, and SRSR; columns fix the [PITH_FULL_IMAGE:figures/full_fig_p026_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Configuration-wise lifecycle profiles by memory type. Rows report MPSR, MESR, E2E-ASR, and SRSR; columns [PITH_FULL_IMAGE:figures/full_fig_p027_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: Configuration-wise lifecycle profiles by primary failure mode. Rows report MPSR, MESR, E2E-ASR, and SRSR; [PITH_FULL_IMAGE:figures/full_fig_p028_11.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

14 extracted references · 12 linked inside Pith

  1. [1]

    Re- membering More, Risking More: Longitudinal Safety Risks in Memory-Equipped LLM Agents

    Al-Tawaha,A.;Gu,S.;Niu,P.;Jia,R.;andJin,M.2026. Re- membering More, Risking More: Longitudinal Safety Risks in Memory-Equipped LLM Agents. arXiv:2605.17830. Chen, Z.; Xiang, Z.; Xiao, C.; Song, D.; and Li, B

  2. [4]

    arXiv:2606.04329

    From Untrusted Input to Trusted Memory: A System- atic Study of Memory Poisoning Attacks in LLM Agents. arXiv:2606.04329. Debenedetti, E.; Zhang, J.; Balunovic, M.; Beurer-Kellner, L.; Fischer, M.; and Tramèr, F

  3. [6]

    arXiv:2604.16548

    A Survey on Long-Term Memory Security in LLM Agents: Attacks, Defenses, and Governance Across the Memory Lifecycle. arXiv:2604.16548. Louck, Y

  4. [7]

    arXiv:2606.24322

    Securing LLM-Agent Long-Term Memory AgainstPoisoning:Non-Malleable,Origin-BoundAuthority with Machine-Checked Guarantees. arXiv:2606.24322. Maharana,A.;Lee,D.-H.;Tulyakov,S.;Bansal,M.;Barbieri, F.; and Fang, Y

  5. [9]

    arXiv:2606.29788

    MemLeak: Diagnos- ing Information Leaks in Multimodal Agent Memory. arXiv:2606.29788. Wu,D.;Wang,H.;Yu,W.;Zhang,Y.;Chang,K.-W.;andYu, D

  6. [10]

    arXiv:2410.10813

    LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory. arXiv:2410.10813. Xie, W.; Guo, S.; Zhang, F.; Xia, T.; Yang, X.; Ma, L.; Yan, J.; and Ren, Q

  7. [11]

    arXiv:2604.15774

    MemEvoBench: Benchmarking Safety Risks from Memory Misevolution in LLM Agents. arXiv:2604.15774. Xu, W.; Liang, Z.; Mei, K.; Gao, H.; Tan, J.; and Zhang, Y

  8. [12]

    Advances in Neural Information Processing Systems, 38: 17577–17604

    A-MEM: Agentic Memory for LLM Agents. Advances in Neural Information Processing Systems, 38: 17577–17604. Xu,Z.; Zhu,X.;Yao, Y.;Xue, M.;andSong, Y.2026. From StoragetoSteering:MemoryControlFlowAttacksonLLM Agents. arXiv:2603.15125. Zhan, Q.; Liang, Z.; Ying, Z.; and Kang, D

  9. [13]

    Zhang, X.; Zheng, Y.; Xu, Z.; Zhou, K.; Shen, B.; Ou, H.; Zhang,T.;andLam,K.-Y.2026.MemMorph:ToolHijacking in LLM Agents via Memory Poisoning

    In- jecAgent: Benchmarking indirect prompt injections in tool- integratedlargelanguagemodelagents.InFindingsoftheAs- sociationforComputationalLinguistics:ACL2024,10471– 10506. Zhang, X.; Zheng, Y.; Xu, Z.; Zhou, K.; Shen, B.; Ou, H.; Zhang,T.;andLam,K.-Y.2026.MemMorph:ToolHijacking in LLM Agents via Memory Poisoning. arXiv:2605.26154. Zou, W.; Dong, M.; C...

  10. [310]

    checkpoint_id

    Figure 6 reports the exact marginals and case-level co-occurrence structure of all four axes. Carrier is the most concentrated: User Interaction contributes 135 cases (43.5%), while the other three carriers jointly contribute 175 (56.5%). Memory Type spans Shared Organizational, Trajectory, External Retrieval, and Profile Memory with 111, 94, 54, and 51 c...

  11. [2023]

    InProceedings of the 16th ACM workshop on artificial intelligence and security, 79–90

    Not what you’ve signed up for: Compromisingreal-worldLLM-integratedapplicationswith indirect prompt injection. InProceedings of the 16th ACM workshop on artificial intelligence and security, 79–90. Hu,Y.;Wang,Y.;andMcAuley,J.2026.EvaluatingMemory in LLM Agents via Incremental Multi-Turn Interactions. In The Fourteenth International Conference on Learning ...

  12. [2024]

    InProceedings of the 62nd Annual Meeting of the Association for Computational Lin- guistics (Volume 1: Long Papers), 13851–13870

    Evaluating very long-term conversa- tional memory of LLM agents. InProceedings of the 62nd Annual Meeting of the Association for Computational Lin- guistics (Volume 1: Long Papers), 13851–13870. Pulipaka, S.; Hlebik, S.; Raghav, L.; Abdelnabi, S.; Raina, V.;Sheth,I.;andFritz,M.2026. HiddeninMemory:Sleeper Memory Poisoning in LLM Agents. arXiv:2605.15338. ...

  13. [2025]

    arXiv:2504.19413

    Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory. arXiv:2504.19413. Das,D.;Piet,J.;Kaviani,D.;Beurer-Kellner,L.;Tramèr,F.; and Wagner, D

  14. [2026]

    arXiv:2605.01970

    Trojan Hippo: Weaponizing Agent Memory for Data Exfiltration. arXiv:2605.01970. Dash, P.; Ge, T.; Jain, A.; Shah, T.; and Shang, Z