← Back to feed
2026-06-29agentsalignmentinfra

Forensic Trajectory Signatures for Agent Memory Poisoning Detection

Jun Wen Leong

PDF preview for Forensic Trajectory Signatures for Agent Memory Poisoning Detection
Read on arXiv →

Key claim

New behavioral invariant improves detection of memory poisoning attacks.

This research uncovers a critical behavioral pattern in LLMs that helps defend against memory poisoning attacks. By exploiting this pattern, the authors achieve high accuracy in detecting such attacks, which is crucial for improving the security of LLM applications.

In plain English

Imagine you're building a system that relies on large language models (LLMs) to handle sensitive tasks, like sending emails or managing data. One major concern is that these models can be tricked into behaving incorrectly through memory poisoning, where malicious inputs manipulate their memory. This can lead to serious security issues, especially if the model is used in critical applications. The challenge is that current defenses often fail to recognize the subtle ways these attacks can manifest, making it hard to distinguish between normal and malicious behavior.

What this paper reveals is a specific pattern in how LLMs behave when they are under attack. It turns out that for an attack to be successful, there’s a particular sequence of actions that the model tends to follow, which is not common in regular operations. This insight allows for a more targeted approach to detecting and preventing these attacks. By focusing on this behavioral invariant, the authors develop a method that significantly improves the accuracy of identifying memory poisoning attempts.

In practical terms, this means that if you're deploying LLMs in environments where security is paramount, you can use this new understanding to build more robust defenses. The paper shows that their method can achieve very high accuracy rates, making it a valuable tool for anyone looking to enhance the security of their LLM applications.

Novelty
8.5/10

The paper identifies a new behavioral invariant in LLMs that enhances understanding of memory poisoning attacks.

Reliability
9.0/10

The findings are supported by extensive evaluations across multiple models and robust statistical analysis.

Deep reliability assessment

The methodology supports the claim that this detector works well for memory-poisoning attacks in agent architectures where memory retrieval is exposed as logged tool calls and the attacker address must be recalled before sending. The broader claim that this is a general forensic signature for agent memory poisoning is more fragile, because it depends heavily on the memory API design, the specific delayed-trigger attack structure, and whether attackers can restructure the payload to avoid the observable recall-before-send transition.

Reproducibility

No public code repository or dataset link is mentioned in the provided paper excerpts. The feature constraints and attack-success labeling rule are described, but reproducing the results would require reconstructing the agent environment, memory tools, attack sessions, model set, and trajectory dataset.

Discussion questions

  1. 1.The core invariant depends on memory access being an observable tool call, especially memory_recall_fact before email_send_email. In the agent stacks people here are building, how often is memory actually exposed this cleanly versus silently injected into context or cached inside the orchestration layer?
  2. 2.The paper treats recall-before-send as mechanistically forced because the attacker address lives in memory. If you were an attacker, would you try to move the routing information into the trigger prompt, encode it in a benign-looking fact key, or use an allowed internal alias instead? Which evasion seems most realistic?
  3. 3.The Random Forest reaches AUC 0.9904, but the simple rule already gets AUC 0.9563. For a production system, would you ship the transparent rule first, or is the extra performance from the 19-feature classifier worth the added opacity and maintenance burden?
  4. 4.The prefix-only detector gets AUC 0.934, while the full-session forensic detector gets AUC 0.990. Would you rather block in real time with more false positives/false negatives, or preserve sessions and do stronger after-the-fact incident response?
  5. 5.The paper argues that removing all recall-related features leaves AUC unchanged, meaning the attack leaves a distributed trajectory signature. What missing experiment would convince you this is not just overfitting to one synthetic workflow or one email-exfiltration task?

Key figure

The key architecture is an agent with persistent memory, observable memory-tool calls, and an email-sending tool, where a delayed memory-poisoning attack leaves a distinctive trajectory because the agent must recall the poisoned routing fact before sending the exfiltration email.

Benchmark results

~evaluated delayed-trigger attack sessions under the paper's agent architectureAUC: 0.9563vs simple recall-before-send ruleN/A
~evaluated delayed-trigger attack sessions under the paper's agent architectureAUC: 0.9904vs Random Forest over 19 trajectory features+0.0341 AUC vs simple recall-before-send rule
~evaluated delayed-trigger attack sessions under the paper's agent architectureAUC: 0.99vs Random Forest ablation without recall-related featuresapproximately unchanged vs full 19-feature Random Forest
~9 held-out model splits across 7B-120B parameter modelsAUC: 1vs cross-model hold-out detectorAUC 1.000 on 6 of 9 hold-out splits
~evaluated delayed-trigger attack sessions using prefix-only tool-call trajectoriesAUC: 0.934vs prefix-only detector-0.0564 AUC vs full-session Random Forest