{"id":"bed6c873-7890-4dee-a334-e3fb7e6936ab","arxiv_id":"2608.00426","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"A memory-lifecycle guard with write, retrieval, promotion, and cross-agent gates reduces memory-poisoning attack success in LLM multi-agent systems from 38.2% to 0.9% and from 34.7% to 0.2% on two benchmarks, while improving benign-task success.","lead":"This paper introduces MAPLE-Guard, a defense that places safety checkpoints on the memory of AI agents, blocking poisoned notes before they can be stored, retrieved, shared, or reused. In tests on five attack-and-task pairs, it lowers attack success from about 38% to under 1% on two memory-heavy benchmarks.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"MAPLE-Guard's efficacy rests on unforgeable runtime metadata; a direct-memory attacker able to set provenance or lineage fields would spoof the two highest-weight signals (Table 5) and likely bypass all four gates.","rationale":"The reader's weakest_assumption is the same one I identify as the single most load-bearing condition: the runtime metadata (provenance, lineage, scope, taint) must be unforgeable. I considered alternative concerns—hand-set hyperparameters without a separate validation set, the approximate INFA-Guard baseline, and single-attack-per-benchmark design—but those affect generalizability or the relative comparison, not the internal soundness of the reported reductions. If the metadata assumption fails, the primary mechanism of the defense is directly nullifiable: an attacker who can write a memory with forged provenance or lineage controls the two largest weights in Eq. (6) and can also set scope to shared and taint to clean, so every gate sees a low-risk item. That is a threat-model boundary, and the paper states it honestly in the Limitation and in A.2, so it is not a red flag of misrepresentation. The result is that the central claim is CONDITIONAL, which is exactly what the reader concluded. My concrete test would settle the question by inspecting whether the implementation actually lets an agent forge metadata; if it does not, the concern does not land. I therefore leave the verdict unchanged.","tokens_in":24007,"tokens_out":10270,"duration_ms":92296,"concrete_test":"Audit the released MAPLE-Guard implementation (github.com/xiong-wenjun/MAPLE-Guard): determine whether the write-memory API accepts caller-supplied metadata (provenance, source-route, scope, parent-lineage) or assigns them system-side. If caller-supplied, run the LongMemEval-MemoryGraft attack using the direct-memory route with forged fields—source-route='tool observation', scope='shared', parent-lineage set to an existing trusted memory—and measure ASR@3 with the fixed guard configuration. If ASR@3 is substantially above the reported 0.9%, the metadata-trust assumption is load-bearing; if the API rejects or overwrites forged metadata, the concern does not land and the central claim stands within its threat model.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim—that the four lifecycle gates reduce ASR from 38.2% to 0.9% on LongMemEval and from 34.7% to 0.2% on AppWorld—holds only if the runtime metadata used by the risk model is trustworthy. Sections 3.2 and A.2 define the hidden state phi(m) = (rho, tau, h, sigma, ell, o) plus provenance chain P(m), and the paper assumes these are not attacker-controllable. The unified risk model in Eq. (6) assigns the largest weights to provenance (0.24) and lineage (0.20) (Table 5); the retrieval score in Eq. (10) also penalizes taint, scope, and the unified risk. If an attacker can forge these metadata fields, the highest-weight signals become adversarial, and the write gate, promotion gate, and cross-agent gate can all be induced to allow a poisoned item. The paper's own Limitation states that 'forged metadata ... may evade the guard,' and Appendix A.2 concedes that the evaluation 'does not cover an attacker who can forge source-route, writer, scope, or lineage records.' This is an explicit scope restriction, not an internal inconsistency. It is load-bearing because the direct-memory route in the threat model (Section 3.2, Figure 2B) lets the attacker seed items into a store it can reach, and the attack-construction template (Figure 8) explicitly stores 'scope, provenance, lifecycle state, and parent lineage metadata' for direct-memory seeding. The paper does not show that the memory manager assigns these fields unforgeably (e.g., via signed system-side instrumentation); without that guarantee, the headline ASR numbers are established only for honest metadata, and the abstract's unqualified claim overstates the tested scope.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper formalizes memory-link poisoning in LLM-based multi-agent systems (MAS), where poisoned memories propagate through write, retrieval, promotion, and cross-agent reuse rather than through observable communication edges. It proposes MAPLE-Guard, a lifecycle-gated defense that maintains per-memory hidden state (utility, provenance trust, content hazard, scope, lifecycle status, outcome history) and applies a single fixed risk model at four gates: write, retrieval, promotion, and cross-agent reuse. The defense is evaluated on five benchmark–attack pairs (MMLU-MINJA, LongMemEval-MemoryGraft, AppWorld-AgentPoison, CSQA-PromptInject, InjectAgent-ToolAttack), two backbones, and multiple topologies. The headline results show ASR@3 falling from 38.2% to 0.9% on LongMemEval and from 34.7% to 0.2% on AppWorld with Qwen3.5-122B-A10B, with MDSR@3 rising from 54.0% to 74.3% and from 42.5% to 99.8%, respectively. An attack-free utility table indicates the guard does not simply block all memory retrieval, and gate ablations isolate the contribution of each lifecycle checkpoint. The paper also reports round-level dynamics, topology and scale stress tests, and a token-cost audit, concluding that memory-aware link enforcement covers a gap left by prompt-level and topology-level defenses.","tokens_in":24325,"tokens_out":9071,"duration_ms":73607,"significance":"If the results hold, MAPLE-Guard would be a meaningful contribution to securing memory-augmented MAS, addressing a propagation channel (the memory lifecycle) that prompt-level and topology-level guards do not directly govern. The paper's strengths include a reproducible protocol with a code release; a clear separation between defense-visible metadata and evaluator-only attack labels; an ablation that isolates each gate; and an attack-free utility check showing that the guard is not merely blocking all memory use. The fixed-configuration claim across five settings is also commendable, though it is qualified by the authors' own statement that it is not proof of generalization to unseen adaptive attacks. The central limitation—reliance on unforgeable runtime metadata—is acknowledged but not resolved, and it directly affects the strength of the headline claims: the ASR/MDSR numbers in Table 1 are conditional on an unverified trust assumption about provenance and lineage records.","major_comments":[{"comment":"The threat model contains an internal tension about who controls the memory metadata. Section 3.2 states that the attacker 'cannot modify ... the guard's hidden signals φ(m)', yet the direct-memory route lets the attacker seed items into a store it can reach, and the attack construction template (Figure 8) explicitly stores 'scope, provenance, lifecycle state, and parent lineage metadata' with the seeded item. The two highest-weight risk signals in Eq. (6) are provenance (weight 0.24) and lineage (weight 0.20) (Table 5). If the memory manager does not cryptographically bind or re-derive these fields from system-side records, an attacker using the direct-memory route can forge the metadata and cause the write, promotion, and cross-agent gates to allow a poisoned item. The paper's Limitation states that 'forged metadata ... may evade the guard', and Appendix A.2 concedes that the evaluation 'does not cover an attacker who can forge source-route, writer, scope, or lineage records.' This scope restriction is load-bearing: the abstract and Table 1 present the ASR/MDSR improvements as the guard's effectiveness without conditioning them on this assumption. The authors should either clarify that the memory manager overwrites attacker-supplied metadata with trusted system-side instrumentation (and explain how this works for the direct-memory route), or evaluate the guard under an attacker with metadata-forging capability and report the resulting ASR/MDSR.","section":"Section 3.2, Appendix A.2, Figure 8, Table 5"},{"comment":"All risk weights, retrieval-score coefficients, outcome-update steps, and gate thresholds are hand-set values. The paper states they were chosen 'once from the normalized signal ranges and gate semantics' without per-benchmark search, which is good, but no sensitivity analysis is provided. Because the gates are threshold policies, the reported ASR/MDSR results hinge on the specific θ_r, θ_ρ, θ_τ, θ_h values and on the weights in Eq. (6). A small perturbation analysis (e.g., ±10–20% in each weight or threshold) would substantiate the claim that the configuration is robust rather than a single point in parameter space that happens to work on the five chosen settings. This matters because the 'one fixed configuration' is presented as a central contribution, and the paper gives no evidence about how quickly performance degrades as the hand-set values are varied.","section":"Appendix A.4, Table 5, Eqs. (6), (8), (9), (11)"},{"comment":"The claim that 'one fixed guard configuration applies across the five evaluated attack settings' is weakened by the fact that all five settings are drawn from the same attack families that motivated the signal design (MINJA, MemoryGraft, AgentPoison, PromptInject, ToolAttack). The PromptInject/CSQA and InjectAgent/ToolAttack pairs are presented as transfer settings, but they are still part of the same benchmark pool used to develop the guard. A true out-of-family test—an attack not among these five families, or an adaptive attack that adjusts after observing the guard's threshold behavior—would be needed to support the abstract's suggestion that the memory-lifecycle approach covers a gap beyond the specific settings. The authors already qualify this in Section 4.2, but the qualification should be reflected in the abstract and conclusion, or a new experiment should be added. Without such an experiment, the generalization claim rests on the same data that motivated the configuration.","section":"Section 4.2, Section 5.3 (Obs3), Table 1"}],"minor_comments":[{"comment":"The relation between the unified risk r(m,c_t) and the action-specific score r_a(e) in Eq. (7) is implicit; the authors should state explicitly that r_a(e) specializes the same unified risk model to each gate action, or define the per-action gating function.","section":"Eqs. (6)–(7)"},{"comment":"The notations 'write hazard & trust h≥0.65, τ≤0.35' and 'promotion hazard or trust h≥0.5 or τ<0.62' are ambiguous. They should be written as explicit blocking conditions, e.g., 'write gate blocks if h≥0.65 and τ≤0.35' and 'promotion gate blocks if h≥0.5 or τ<0.62'.","section":"Table 5"},{"comment":"The abbreviations WG, RG, PG, and CG are used in the figure but defined only in the text; they should be defined in the caption itself.","section":"Figure 5 caption"},{"comment":"The phrase 'lowest ASR@3 in every setting' should be scoped to the controlled-topology main grid. In the random-topology stress test (Table 4), AgentXposed ties MAPLE-Guard at 0.0% ASR on AppWorld with the Qwen backbone.","section":"Section 5.3, Obs3"},{"comment":"For the 30- and 50-agent stress tests, the number of attacker-controlled agents is unspecified. The main grid uses 3 of 8; it is unclear whether the attacker ratio (3/8) or the absolute number (3) is held constant when scaling to 30 and 50 agents.","section":"Section 5.1, Appendix C, Table 3"},{"comment":"The outcome update ρ_{n+1}(m) = (1−α)ρ_n(m) + αR_n does not state whether R_n is normalized or raw; this affects the scale of ρ relative to the promotion thresholds θ_ρ used in Eq. (11). Please specify the range of R_n.","section":"Eq. (4)"}],"recommendation":"major_revision","confidential_remarks":"This manuscript is likely to interest the multi-agent safety community, and the reproducible evaluation is a clear strength. The main risk is the metadata-forgery gap: the threat model explicitly includes a direct-memory route, yet the evaluation excludes an attacker who forges provenance or lineage records, which are the highest-weight signals in the risk model. I recommend major revision rather than rejection because the core idea is sound and the limitation is honestly acknowledged. If the authors can either enforce metadata integrity with a trusted memory manager or evaluate against forging attackers, the work would be suitable for acceptance. The hand-set threshold sensitivity issue is secondary but should be addressed with a perturbation analysis."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nYou should know this paper is worth your time. It's the first MAS defense I've seen that treats memory-lifecycle transitions as first-class attack surface, and it does the evaluation properly: five benchmark-attack pairs, two backbones, three controlled topologies plus random-graph stress tests, a gate ablation, and a benign-utility check. The numbers are internally consistent, and the fixed risk model with no per-attack tuning is a real strength. The four-gate design is a sensible combination of provenance tracking and Q-value memory management, and the paper is honest about what it does not show.\n\nThe main soft spot is the one the authors admit in their limitation: the guard assumes runtime metadata—provenance, lineage, writer identity—is unforgeable. That assumption is load-bearing because provenance and lineage carry the largest weights in the risk model. The threat model explicitly says the attacker cannot modify hidden signals, so within that boundary the results hold. But the abstract drops the qualifier, and a direct-memory attacker who can set metadata fields would probably walk through all four gates. That's an important scope restriction, not an internal inconsistency.\n\nThree smaller issues. First, the gate thresholds and signal weights are hand-set with no described validation split; five attack families is a small sample to claim generalization. Second, INFA-Guard is an approximation over a shared interface, not a faithful reproduction, so the comparison table should be read with that in mind. Third, the code link is given but there's no commit hash or data release, so the central claim isn't independently reproducible from the paper. Also, each benchmark is paired with a single attack, so the evaluation doesn't isolate the effect of the attack entry point; the authors note this too.\n\nNone of this breaks the central claim within its stated threat model. The paper is a genuine advance for AI-agent security, and a serious referee would help by pushing the authors to separate the honest-metadata result from a stronger claim, and to test at least one adaptive attack that can forge or spoof metadata.\n\nRecommendation: send it to review. It deserves a shot, with the metadata question front and center.\n\nBest,\n[You]","headline":"A thorough, genuinely novel defense against memory poisoning in MAS, but its headline numbers assume unforgeable runtime metadata; worth a serious referee.","tokens_in":24958,"tokens_out":2147,"would_cite":true,"duration_ms":19578,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"MAPLE-Guard treats persistent memory as governed state at four lifecycle gates—write, retrieval, promotion, and cross-agent reuse—and, with one fixed risk model, cuts attack success on memory-native benchmarks to under one percent while…","keywords":["memory-link poisoning","multi-agent systems","persistent memory security","lifecycle gates","provenance trust","LLM agents","defense evaluation","attack success rate"],"falsifier":"Run the same five benchmark–attack settings but give the attacker the ability to write memory items whose provenance metadata names a trusted internal agent and whose lineage chain never crosses agents or private-to-shared promotion; if ASR@3 then approaches the no-defense level (for example, above 10% on LongMemEval), the guard's dependence on unforgeable metadata is demonstrated. A second check: an attacker who knows the fixed weights and thresholds in the risk model crafts a poisoned memory with low instruction-likeness, low trigger sensitivity, and a single trusted parent, and the guard's ASR@3 is measured; values near baseline would show that the fixed model is brittle to adaptive payload tuning.","tokens_in":23738,"feed_emoji":"🛡️","tokens_out":7326,"duration_ms":59068,"temperature":0.7,"pith_summary":"LLM-based multi-agent systems with persistent private and shared memories create a durable attack channel: a poisoned memory written once can later be retrieved, promoted, and reused by other agents, steering decisions long after the malicious interaction ended. The paper formalizes this as memory-link poisoning, in which harmful content travels along memory-lifecycle dependencies rather than visible communication edges. It proposes MAPLE-Guard, a guard that intercepts memory operations at four lifecycle gates—write, retrieval, promotion, and cross-agent reuse—and scores every memory with one fixed risk model built on provenance, lineage, content, and learned utility. Across five benchmark–attack pairs and two backbones, the guard lowers attack success on LongMemEval from 38.2% to 0.9% and on AppWorld from 34.7% to 0.2%, while improving multi-agent defense success. The paper argues this coverage is complementary to prompt- and topology-level defenses, which miss attacks that look benign when stored.","feed_headline":"Four memory gates cut attack success from 38% to 0.9%","feed_subtitle":"Guarding write, retrieval, promotion, and reuse of agent memory beats prompt-level defenses and raises correct consensus.","key_machinery":"The central object is the memory-link event and path: e=(u,v,m,a,t) records that memory item m moved from source u to target v via lifecycle action a at round t, and a path is the ordered sequence of such events for one item. This object shifts the intervention surface from the communication graph to the memory lifecycle, because a path can cross agents through shared memory without any direct message. The scoring machinery is a unified risk model r(m,c_t) = Σ w_k r_k(...) over eight signals (provenance, lineage, self-claimed success, instruction-likeness, answer binding, trigger sensitivity, cluster dominance, and source-agent trust), with provenance weight 0.24 and lineage weight 0.20; a threshold policy (allow/demote/block) applies the same model at all four gates, and a Q-style outcome update ρ_{n+1}=(1−α)ρ_n+αR_n plus a provenance-trust update adjusts each item's value after every task.","core_discovery":"The central claim is that treating memory as governed state—rather than only screening prompts, actions, or communication edges—can contain memory-link poisoning. A memory item carries hidden metadata (provenance, lineage, scope, lifecycle state, trust, and utility), and each write, retrieval, promotion, or reuse creates a memory-link event that can be scored and gated. With one fixed, hand-set risk model (no per-attack tuning), the write gate quarantines or rewrites risky items, the retrieval gate filters before memory enters the prompt, the promotion gate blocks private-to-shared transitions for untrusted items, and the cross-agent gate denies reuse by other agents. The empirical claim is that this lifecycle enforcement reduces attack success below one percent on the two memory-native benchmarks and raises multi-agent defense success substantially, while transfer settings and ablations indicate the gains come from blocking memory paths rather than from oracle labels or per-attack detection.","pith_inferences":["If provenance and lineage metadata were cryptographically signed or recorded in a tamper-evident log, the guard's two highest-weight signals could be hardened against the forgery that the paper identifies as its main limitation; this is an extension the paper does not implement.","The risk model's weights (provenance 0.24, lineage 0.20) reward short, trusted lineage, so an adaptive attacker could attempt to launder a poison by rewriting it through several benign-looking agents to dilute lineage risk; testing this would reveal whether multi-hop provenance laundering defeats the fixed model.","Because utility and trust rise after task success, a poison that helps the agent on a few benign tasks before steering a harmful outcome could accumulate trust and become harder to block at the promotion gate; a delayed-harm attack variant would be a direct test of this temporal weakness.","The guard cuts token use by 27–35% in a controlled audit, which suggests that lifecycle filtering has a side benefit of pruning irrelevant memories; a natural follow-up is to measure whether this token saving persists on longer-horizon tasks with larger memory stores."],"forward_implications":["A single fixed guard configuration, evaluated without per-attack threshold search, reduces ASR below 1% on LongMemEval and AppWorld (0.9% and 0.2%), suggesting that one memory-lifecycle filter can cover multiple known attack families.","Removing the promotion gate on LongMemEval drops MDSR from 73.60% to 60.00% and raises ASR from 0.90% to 14.50%, so private-to-shared promotion is the critical propagation point to defend.","Under random communication topologies and at 30- and 50-agent scale, the guard still keeps ASR below the no-defense baseline, and its deterministic gates add no guard-LLM calls, so the defense's cost is mostly metadata bookkeeping.","On tool-use benchmarks, the guard simultaneously lowers poisoned-memory use rate, agent-level poisoned-memory exposure, and security-probe failures, consistent with the claim that blocking memory paths—not just screening visible messages—drives the defense.","On the transfer setting (PromptInject/CSQA), the same fixed configuration reduces ASR from 37.7% to 23.6%, indicating some generalization beyond the exact attack families used for the memory-native pairs."],"supporting_citations":[{"why":"Defines the AgentPoison attack, the tool-action memory-poisoning benchmark used in the AppWorld evaluation.","marker":"[3]"},{"why":"Defines the MINJA memory-injection attack used in the MMLU benchmark pair.","marker":"[7]"},{"why":"Defines the MemoryGraft poisoned-experience attack used in the LongMemEval benchmark pair.","marker":"[27]"},{"why":"Defines the PoisonedRAG retrieval-corpus attack, one of the poisoning families the guard is designed to contain.","marker":"[48]"},{"why":"Supplies the dynamic taint-tracking principle that risk inherits from untrusted or cross-agent parents in the provenance chain.","marker":"[19]"},{"why":"Provides the reinforcement-learning memory substrate whose Q-value is used as the guard's utility estimate and outcome update.","marker":"[42]"},{"why":"Provides evidence of longitudinal safety risks in memory-equipped agents, motivating the persistence and cross-task propagation model.","marker":"[1]"},{"why":"G-Safeguard is the topology-level baseline that the guard must beat, intervening on communication paths rather than memory links.","marker":"[33]"},{"why":"INFA-Guard is the infection-aware communication baseline used for comparison, again operating on visible edges rather than memory lifecycle events.","marker":"[46]"}],"fun_headline_variants":["Memory gates slash attack success from 38% to 0.9%","Four memory lifecycle gates cut poisoning to under 1%","MAPLE-Guard: block poisoned memories before they spread","Memory link enforcement: ASR from 38% to 0.9% via four gates"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The guard assumes the runtime metadata that drives its risk scores—provenance, writer identity, scope, lineage, and verification state—is accurate and cannot be forged by an attacker; if those records can be spoofed, the two highest-weight signals collapse and the gates can be bypassed.","fun_headline_variants_meta":{"raw":{"variants":["Memory gates slash attack success from 38% to 0.9%","Four memory lifecycle gates cut poisoning to under 1%","MAPLE-Guard: block poisoned memories before they spread","Memory link enforcement: ASR from 38% to 0.9% via four gates"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000744,"raw_usage":{"total_tokens":3373,"prompt_tokens":1055,"completion_tokens":2318,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":671,"completion_tokens_details":{"reasoning_tokens":2239}},"tokens_in":671,"tokens_out":2318,"duration_ms":15368,"temperature":1.0,"reasoning_tokens":2239,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T15:19:54.278776+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the same five benchmark–attack settings but give the attacker the ability to write memory items whose provenance metadata names a trusted internal agent and whose lineage chain never crosses agents or private-to-shared promotion; if ASR@3 then approaches the no-defense level (for example, above 10% on LongMemEval), the guard's dependence on unforgeable metadata is demonstrated. A second check: an attacker who knows the fixed weights and thresholds in the risk model crafts a poisoned memory with low instruction-likeness, low trigger sensitivity, and a single trusted parent, and the guard's ASR@3 is measured; values near baseline would show that the fixed model is brittle to adaptive payload tuning.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines the MINJA memory-injection attack used in the MMLU benchmark pair."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines the AgentPoison attack, the tool-action memory-poisoning benchmark used in the AppWorld evaluation."},{"cited_title":"poisoned","cited_arxiv_id":null,"evidence_quote":"Defines the PoisonedRAG retrieval-corpus attack, one of the poisoning families the guard is designed to contain."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the dynamic taint-tracking principle that risk inherits from untrusted or cross-agent parents in the provenance chain."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"G-Safeguard is the topology-level baseline that the guard must beat, intervening on communication paths rather than memory links."}],"review_version":2}