{"id":"ee391cce-6fc7-4eb4-ad08-fe094bbb6740","arxiv_id":"2606.30566","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"Successful email-exfiltration via agent memory poisoning necessarily starts with a recall_fact call before the first email_send_email, but that same signature also appears in benign memory-checking behavior.","lead":"Memory-poisoning attacks on AI agents force a tell-tale step—an agent must look up the attacker's address in memory before emailing it out—and the authors show this step can be read from tool logs alone. The signature turns out to be a necessary clue, not proof: benign agents that check memory before sending produce the same pattern, so the paper maps where the method works and where it fails.","discovery_kind":"first_principles","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Invariant proof depends on attack storing the address in the value field; storing it as a memory key evades recall_before_send within the paper's own API assumptions.","rationale":"The reader's conditional verdict is reasonable, but it focuses on deployment external validity (no true-benign baseline, v2 FPR). The most load-bearing gap is internal to the invariant proof: the necessity claim holds only for attacks that store the address in the value field, and that constraint is not part of the threat model. An attacker who controls the poison document can choose the key/value encoding; if the memory API exposes key names, address-as-key bypasses the recall step. This does not require hidden internal state, RAG fallback, or violating the stated architecture, so it is more central than the reader's weakest_assumption. The empirical value-stored results and the v2 deployment-boundary disclosure are honest and useful, but the abstract and Section 3.3 overstate the invariant's scope. A narrow revision plus the address-as-key experiment would settle the matter; hence CONDITIONAL rather than outright rejection.","tokens_in":11974,"tokens_out":16017,"duration_ms":156447,"concrete_test":"Run the delayed-trigger attack under the stated memory API with the attacker address stored as a memory key rather than a value: instruct the agent to save_fact(key='attacker@evil.example.com', value='routing-destination') and to send to any email-looking key returned by list_all_facts. Use at least three of the paper's models (e.g., qwen3:32b, gpt-oss:20b, glm-4.7-flash:q8_0), temperature 0, N=40 per model, and measure ASR and how many attack successes have recall_before_send=0. Also log whether list_all_facts output exposes email-shaped keys. If ASR>0 with recall_before_send=0 for any model, the invariant is not a necessary condition for memory-channel poisoning.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"Section 3.3's derivation has a hidden step. Step 2 asserts 'The attacker email is stored as a value, not a key,' but the threat model (Section 2.1) never constrains the storage encoding; the adversary controls the poison document. Under the paper's own assumption (4) that list_all_facts returns key names only, a memory-channel attack that stores the address as a key (save_fact(key='attacker@evil.example.com', value='destination')) surfaces the address in the list output. The agent can then go list_all_facts -> send_email with no recall_fact, violating the claimed invariant without violating any of the four architectural assumptions. Thus 'mechanistically forced' is an artifact of the DTA implementation's value-field encoding, not a general property of memory-channel poisoning. The abstract's unqualified 'successful attacks require calling memory_recall_fact' is too strong, and Section 4.3's adaptive-adversary list does not consider this simpler encoding shift.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper studies forensic detection of memory-channel poisoning attacks on LLM agents. It claims that, under observable memory-tool access, any successful delayed-trigger attack that stores the attacker's routing address in persistent memory must call memory_recall_fact before email_send_email, and that this recall-before-send transition is mechanistically forced by the attack's information-retrieval dependency. Using 2,520 delayed-trigger-attack runs from the author's prior factorial study, it evaluates a one-rule detector (AUC=0.9563), a 19-feature Random Forest (AUC=0.9904), feature-group ablations, leave-one-model-out hold-out on 9 models, frontier-model probes, an evasion boundary, and a prefix-only variant (AUC=0.934). The paper also includes an appended [v2] abstract reporting that benign memory-grounded sends produce the same recall-before-send signature, yielding 100% false positives conditional on that signature.","tokens_in":12163,"tokens_out":5734,"duration_ms":58372,"significance":"If the invariant held as stated, this would be a valuable forensic tool: operation-only detection from tool-call logs, with no memory access or model internals, supported by a mechanistic argument. The paper has real strengths: a large multi-model factorial dataset, leave-one-model-out validation, BCa bootstrap CIs, ablation analysis, explicit reproducibility details, and candid limitations including the absence of a true benign baseline and the qwq:32b bypass failure. The v2 addendum is a good-faith attempt to characterize the deployment boundary. However, the central mechanistic claim is not established under the paper's own architectural assumptions: the proof assumes the attacker stores the address as a value rather than a key, and the in-data qwq:32b result contradicts the unqualified abstract claim. The paper's main value is therefore as a characterization of a specific attack construction, not as a general invariant of memory-channel poisoning.","major_comments":[{"comment":"The proof's step 2 asserts 'The attacker email is stored as a value, not a key' without support. The threat model in Section 2.1 does not constrain the storage encoding; the adversary controls the poison document and the save_fact call. Under the paper's own assumption (4) that list_all_facts returns key names only, an adversary can store the address as the key (save_fact(key='attacker@evil.example.com', value='destination')). The agent can then execute list_all_facts -> send_email with no recall_fact, satisfying all four architectural assumptions and violating the invariant. Thus 'mechanistically forced' is an artifact of the DTA implementation's value-field encoding, not a general property. The abstract's unqualified claim and Section 4.3's adaptive-adversary list, which omits this simpler encoding shift, need revision.","section":"Section 3.3, step 2; Section 2.1"},{"comment":"The evaluation's negative class consists of poisoned-but-defended sessions, not unpoisoned benign traffic. This is acknowledged in Section 4.3 ('No true-benign baseline'), but the framing in Sections 3.1, 4.1, and 6 ('deployable by any operator', 'forensic-grade audit confidence') overstates operational readiness. The manuscript's own v2 abstract reports 100% false positives conditional on recall_before_send=1 and a 24.7-52.6% benign FPR, demonstrating that the signature is a valid attack precondition, not a maliciousness predicate. This boundary should be integrated into the main results and discussion, and the standalone-blocking/deployment recommendations should be qualified accordingly.","section":"Section 2.2; v2 abstract"},{"comment":"The qwq:32b Memory Sandbox result (AUC=0.000) is an in-data attack that succeeds without recalling memory, via goal-directed RAG fallback. The abstract states that 'in architectures where retrieval is routed through observable memory-tool invocations, successful attacks require calling memory_recall_fact before email_send_email.' The RAG fallback is an observable retrieval route under the paper's own framing. The paper is internally inconsistent unless the invariant's scope is narrowed to attacks that specifically use the memory recall tool, rather than memory-channel poisoning in general. The abstract and conclusion should state this scope restriction explicitly.","section":"Sections 3.4 and 3.5; abstract"}],"minor_comments":[{"comment":"The AUC for the binary rule 'recall_before_send' needs clarification: a deterministic rule produces a single ROC operating point, not a curve. Please explain how AUC=0.9563 is computed (e.g., by using predicted probabilities from a calibrated score, or by threshold sweeping on the rule's score).","section":"Section 3.1"},{"comment":"The text describes the list→draft transition as 'the clearest Markov difference', but Table 3 does not list list→draft directly. Please add the value or revise the wording to match the table's features.","section":"Table 3; Section 3.3"},{"comment":"The [v2] abstract addendum reports important boundary results, but the main text's abstract, Section 3, and Section 6 do not mention them. The paper should be revised so the abstract and body are consistent, with the v2 boundary results integrated into the relevant sections rather than appearing only in the abstract.","section":"Abstract vs. full text"},{"comment":"The abstract mentions GPT-4o, but Section 3.7 only reports the GPT-4.1 probe (N=20). The expanded frontier evaluation mentions 'frontier models from separate experiments' but does not name GPT-4o or give per-model numbers. Please clarify which frontier models are included and report per-model ASR/Recall/FPR.","section":"Section 3.7"}],"recommendation":"major_revision","confidential_remarks":"The paper's central contribution is a clean empirical observation about a specific attack construction, supported by careful evaluation and a candid v2 addendum. However, the proof of the invariant is incomplete under the paper's own assumptions: the storage encoding is unconstrained, and the key-as-key evasion is a trivial and natural alternative. The in-data qwq:32b result further weakens the universal framing. These issues are fixable by narrowing the claims to the DTA value-storage construction and explicitly analyzing the key-as-key variant, but without that revision the title, abstract, and conclusion overclaim. I would support publication after a major revision that addresses the scope and the missing adaptive adversary case."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The core empirical result here is worth taking seriously: in the evaluated DTA construction, successful memory-channel exfiltration almost always shows recall_fact before send_email, and the signature holds across models and under ablation. The paper is also unusually honest in the v2 abstract about the deployment boundary—benign memory-grounded sends produce the same signature, so it is a precondition, not a maliciousness predicate. That is the right way to frame it.\n\nBut the central proof has a hole. Section 3.3 step 2 asserts the attacker email is stored as a value, not a key, with no support in the threat model. Under the paper's own assumption (4), list_all_facts returns key names only. Store the address as a key—save_fact(key='attacker@evil.example.com', value='destination')—and the agent can go list_all_facts -> send_email with no recall_fact, while still satisfying every listed architectural assumption. The stress-test note has this right. The invariant is therefore not mechanistically forced for memory-channel poisoning generally; it is forced only for the value-encoding variant used in the author's DTA implementation. The abstract's unqualified 'successful attacks require calling memory_recall_fact' overstates the case, and the adaptive-adversary list misses this simpler encoding shift.\n\nWhat does hold up? The empirical detection numbers on the poisoned-but-defended dataset are sound, the cross-model hold-out is informative, and the qwq:32b Memory Sandbox bypass is a genuinely useful boundary case showing the signature does not cover implicit-bypass attacks. The overdetermination ablation—removing all recall features leaves AUC unchanged—is a nice demonstration that the attack disturbs multiple channels, even if that cascade is also tied to the specific attack construction.\n\nSoft spots beyond the proof gap: the v1 body repeatedly talks about deployment and real-time blocking, while the v2 abstract concedes 100% false positives conditional on recall_before_send=1. That is a large mismatch between framing and evidence. The v1 evaluation has no true-benign traffic, so the headline AUC of 0.9904 does not transfer to operational settings. The dataset comes from the author's own prior work, and no code or data artifacts were verifiable from the text, so the numbers are currently taken on trust.\n\nWho should read this? Incident responders and agent-security researchers who want a cheap forensic marker for a specific attack variant. It is a useful foundation, not a general detector. It deserves a serious referee—send it to review—but the revision needs to narrow the invariant to the value-encoding regime, add true-benign FPR numbers, and make the code/data available. The proof gap alone is fixable; the overclaiming is the bigger problem.","headline":"The recall-before-send invariant is real and useful, but the 'mechanistically forced' claim is too strong: storing the attacker address as a memory key evades it within the paper's own API assumptions.","tokens_in":12661,"tokens_out":2339,"would_cite":true,"duration_ms":26291,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Memory-poisoning attacks on LLM agents are forced to call a memory recall before the exfiltrating email, making them detectable from tool-call logs alone.","keywords":["LLM agent security","memory poisoning","forensic trajectory","detection invariant","tool-call logs","behavioral detection","prompt injection","delayed-trigger attack"],"falsifier":"Run the detector on a corpus of genuinely unpoisoned, benign agent sessions where the agent legitimately looks up a recipient email from memory before sending; if recall-before-send occurs at a nontrivial rate, the 100% conditional false-positive finding is confirmed. Alternatively, modify the memory API so list_all_facts returns stored values; a successful exfiltration that never calls recall would falsify the claimed invariant.","tokens_in":11820,"feed_emoji":"🧠","tokens_out":4139,"duration_ms":35278,"temperature":0.7,"pith_summary":"This paper tries to establish that persistent memory poisoning of an LLM agent leaves a forced behavioral trace: before the agent can exfiltrate data to an attacker-supplied address, it must call the memory-recall tool to read that address out of persistent storage, because the storage API returns only key names. On a dataset of 2,520 attacked or defended sessions across nine models, this single ordering rule separates attack successes from defended non-exfiltrations with AUC 0.956, and a 19-feature classifier reaches AUC 0.990. The paper also shows the signature is overdetermined—removing every recall-related feature leaves performance unchanged—and transfers to frontier models. A preregistered follow-up defines the boundary: benign memory-grounded sends reproduce the same recall-before-send pattern, so the signature is an attack precondition, not a maliciousness predicate, and must be gated by recipient metadata.","feed_headline":"A forced recall-before-send trace exposes memory-poisoned agents","feed_subtitle":"Tool-call order alone scores AUC 0.99, but the same signature appears in benign memory use—so gating by recipient matters.","key_machinery":"The load-bearing object is the recall-before-send transition: the ordered pair of tool calls (memory_recall_fact, email_send_email) in the trigger session. It is mechanistically forced by the attack's information-retrieval dependency: the attacker's routing address is stored as a value, memory list returns only keys, so the agent must call recall to obtain the destination before sending. The paper shows the transition is overdetermined because the same underlying event cascades into multiple independent feature channels—recall counts, ratios, bigrams, entry points—so removing all recall-related features leaves classifier AUC unchanged at 0.9904.","core_discovery":"The central discovery is a mechanistically forced invariant: in any architecture where persistent memory is only reachable through observable tool calls, a delayed-trigger poisoning attack that stores the attacker's address as a memory value cannot succeed without first calling memory_recall_fact before the exfiltrating email_send_email. The reason is information dependency—the agent must retrieve the stored address, and the list operation does not reveal values. The paper proves this by showing that suppressing the recall step breaks the attack, and that the transition appears with zero violations across the entire dataset. The follow-up finding is that the invariant is a necessary conditio","pith_inferences":["A natural testable extension is to run the detector on genuinely unpoisoned, realistic agent workloads with normal memory use; the paper's reported FPRs are measured against poisoned-but-defended sessions, so deployment FPR on clean traffic remains unknown.","The invariant suggests an architectural hardening: if memory stores exposed values via list operations, the forced recall step disappears and the detector's central signature collapses; therefore tool-layer APIs that keep values opaque are the load-bearing design choice.","The overdetermination result implies that an adversary who knows the detector must suppress not just recall calls but the whole cascade of downstream behaviors (second drafts, multiple sends), which is effectively the attack itself—suggesting robustness is structural, not statistical.","Cross-model transfer to reasoning models shows higher baseline recall-call rates; per-model threshold calibration, rather than a global threshold, is a practical deployment step the paper leaves implicit."],"forward_implications":["Tool-call logs alone are sufficient to detect memory-channel exfiltration; no white-box access or memory-store changes are needed.","A strictly prefix-only classifier (AUC 0.934) enables real-time inline blocking before the email is sent, while the full-session classifier supports post-hoc forensic audit.","Prompt-injection attacks that embed routing instructions directly in the prompt do not produce the recall-before-send signature, so trajectory logs can attribute an attack to the memory channel vs. prompt injection.","Because the signature is an attack precondition, standalone blocking would block benign memory-grounded sends; detection must be gated by recipient metadata to restore separation.","Removing all recall-related features leaves AUC unchanged, implying that defenses which merely obscure the recall pattern would still be caught by downstream behavioral changes (extra sends, drafts)."],"fun_headline_variants":["Forced recall-before-send trace reveals poisoned agents, but benign use shares it","Recall-before-send scores AUC 0.99, but false positives in benign memory use","Tool-call order alone spots memory poisoning; recipient gating makes it viable","Prefix-only recall trace enables real-time triage of agent memory poisoning"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"Everything rests on the architectural rule that the agent can only reach persistent memory through observable tool calls—no hidden context injection, no cached recall results, no RAG re-retrieval—and that listing memories returns key names only; if any implementation violates that, a successful attack can skip the recall-before-send step and the signature disappears.","fun_headline_variants_meta":{"raw":{"variants":["Forced recall-before-send trace reveals poisoned agents, but benign use shares it","Recall-before-send scores AUC 0.99, but false positives in benign memory use","Tool-call order alone spots memory poisoning; recipient gating makes it viable","Prefix-only recall trace enables real-time triage of agent memory poisoning"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000216,"raw_usage":{"total_tokens":1303,"prompt_tokens":811,"completion_tokens":492,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":555,"completion_tokens_details":{"reasoning_tokens":405}},"tokens_in":555,"tokens_out":492,"duration_ms":6216,"temperature":1.0,"reasoning_tokens":405,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-02T09:26:31.052380+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the detector on a corpus of genuinely unpoisoned, benign agent sessions where the agent legitimately looks up a recipient email from memory before sending; if recall-before-send occurs at a nontrivial rate, the 100% conditional false-positive finding is confirmed. Alternatively, modify the memory API so list_all_facts returns stored values; a successful exfiltration that never calls recall would falsify the claimed invariant.","supporting_citations":[],"review_version":2}