Skip to main content
LLM Security Database
Skip to research details
Back to research findings
LMVD-ID: 718886f2
Paper published July 29, 2026
Entry analyzed August 13, 2026
Paper-reported evidence
Confidence: Source-linked

The LMVD-ID is an internal research identifier, not an official CVE identifier.

Persistent Agent Memory Poisoning and Incomplete Repair

MemSecBench follows malicious agent-memory content from initial write through persistence, retrieval, action selection, execution, and attempted selective repair. Its controlled Write–Execute–Forget protocol evaluates…

Read primary paperBibTeX citation

Paper-evaluated models(3)

  • GPT-5.5
  • DeepSeek V4-Pro
  • MiniMax-M3

Description

MemSecBench follows malicious agent-memory content from initial write through persistence, retrieval, action selection, execution, and attempted selective repair. Its controlled Write–Execute–Forget protocol evaluates 310 human-reviewed cases across two harnesses, four memory backends, three model backends, and seven evidence-gated lifecycle checkpoints.

Examples

Evaluate memory handling with isolated workspaces, synthetic records, inert side effects, controlled write and retrieval traces, and independent checks that benign memories survive repair; see https://arxiv.org/html/2607.27080 (opens in a new tab).

Impact

Across 24 matched harness-memory-model configurations, malicious memory persists in 84.2% of cases and the complete write-to-execution chain succeeds in 50.3%. Among successfully poisoned cases, selective repair succeeds in 56.1%; that repair rate has a conditional denominator and cannot be compared directly with the all-case execution rate. Authored sandbox cases, single runs, simulated effects, and use of a model judge limit broader claims.

Affected Systems

  • Hermes and OpenClaw agent harnesses under the paper’s evaluated memory configurations
  • Native agent memory, Mem0, Mem0-Graph, and A-MEM persistent-memory backends
  • Agent workflows that write, retrieve, apply, update, or selectively delete persistent cross-task memory

Mitigation Steps

  • Bind persistent memory to its original source, authority, task scope, and creation time before allowing later retrieval.
  • Separate untrusted observations from trusted standing instructions and never promote retrieved memory into higher-authority policy.
  • Apply authorization checks before executing actions suggested by retrieved memory.
  • Audit memory poisoning across write, persistence, retrieval, adoption, execution, and repair rather than measuring only initial injection.
  • Test selective repair for both removal of malicious semantics and preservation of required benign memories.

Evidence

Research context and confidence

Evidence and verification
Paper-reported; independent reproduction is not documented.
Primary source plus a dedicated evidence section.
Severity
Not rated by this catalog.
Source and publication type
arXiv · Research preprint.
Peer-review status is not provided by this source.
Author and publication status
Author metadata is not stored; see the primary paper.
Threat model and attacker access
Ability to influence untrusted model inputs or connected content.
Related deployment categories
Agent workflows; Agent memory; Coding agents
Taxonomy labels only; paper-specific deployment prerequisites are not inferred.
Affected systems
Hermes and OpenClaw agent harnesses under the paper’s evaluated memory configurations Native agent memory, Mem0, Mem0-Graph, and A-MEM persistent-memory backends Agent workflows that write, retrieve, apply, update, or…

Research Paper

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

Primary source: arXiv. Findings are reported by the cited research and have not been independently verified.

View Paper