AI Agent Memory Poisoning にはライフサイクル全体の防御が必要

AI agent memory poisoning は、信頼できない入力を永続的な状態へと変えてしまいます。agent が攻撃者に制御されたコンテンツを persistent memory に書き込むと、そのコンテンツは数日後、あるいは別のセッションで、信頼できるコンテキストのように戻ってくる可能性があります。ライフサイクル全体を防御してください。すべての書き込みをゲートし、provenance と有効期限を付与し、ユーザーと agent ごとにレコードを分離し、retrieval を再スクリーニングし、action authorization を model の外部に保持し、ロールバックを支援する influence log を維持します。

目次

AI agent memory poisoning とは何か

AI agent memory poisoning とは、永続レコードを挿入または変更し、後の retrieval によって agent の回答、判断、または tool use が変化するようにすることです。影響が現れた時点では、元の入力がすでに消えている場合があります。この時間差により、現在の会話における目に見える prompt injection よりも、攻撃の発見と再構成が難しくなります。

Memory は複数の場所に存在します。

ストレージ技術が本質的な問題なのではありません。永続性と、その後の影響力の組み合わせが security boundary を作ります。

これは、隣接する3つのリスクとは異なります。Prompt injection は現在の model context を操作しますが、汚染された memory の delivery channel になることもあります。Training-data poisoning は training corpus を通じて model behavior を変えます。Retrieval poisoning はリクエストに対して選択されるコンテンツを標的にします。Agent-memory poisoning は、システムが後にユーザーの履歴、好み、または operating state の一部として扱う可能性のあるレコードを永続化します。

実務上、重要な攻撃パターンは3つあります。

Microsoft の現在の guidance は、同じ構造的な懸念を防御の観点から説明しています。persistent memory は sensitive data を保存するだけでなく、model behavior と tool selection にも影響を与えます。そのため、data system と control plane の両方として管理すべきです。Microsoft Learn

最近の3つの研究が測定したもの

2026年7月に公開された3本の preprint は、この脅威の異なる部分を調査しました。まとめて読むと、単一の memory filter が弱い release criterion である理由が分かります。

GhostWriter は、今の injection と後の activation を検証した

When Agents Remember Too Much は、tool-using personal agent に対する2段階攻撃である GhostWriter を導入しました。攻撃者はまず、信頼できない source に hidden content を配置します。agent はその source を処理し、攻撃者の影響を受けた memory を書き込みます。後の task がそのレコードを retrieval し、影響を activation します。

論文で検証された agent と model 全体では、GhostWriter は平均 injection rate 約98%、平均 activation rate 約60%に達しました。著者らは、より厳格な memory-saving policy と retrieval screen を組み合わせた AM-Sentry も検証しました。この論文は、独自の simulated workweek において attack success と task utility の両方を評価しています。防御結果は model と configuration によって異なります。

境界条件は重要です。この研究は5つの agent、4つの model family、email または calendar workflow を対象としています。utility test は独自設計であり、攻撃者は adaptive ではなく、結果は deployed agent が攻撃される頻度を推定するものではありません。

MemPoison は direct、compositional、dormant の失敗を分離した

MemPoison は、4種類の攻撃、3つの injection channel、3つの memory substrate にまたがる、hand-validated な1,227件のケースを構成しました。評価には、7つの open-weight model family と3つの closed-weight model family が含まれています。

この論文の有用な貢献は、3段階の taxonomy です。L1 は単一レコードの direct corruption です。L2 は、複数のレコードが一緒に retrieval されたときに有害になります。L3 は、後の context が activation するまで dormant のままです。著者らは、baseline write-time defenses が direct attack を L2 または L3 のケースよりも確実に抑制すると報告しています。mechanistic influence analysis では、保存時には benign に見えるものの、composition または trigger によって有害になるレコードが、この差の原因だとしています。

これは、すべての production write filter が失敗することを証明するものではありません。この benchmark は、代表的な3つの memory substrate と標準的な text-based channel を対象としています。著者らは、decay、summarization、access controls、その他の memory ecosystem に関する、より広範な研究を求めています。

MemGhost は one-shot email delivery path を検証した

When Claws Remember but Do Not Tell は、real IMAP/SMTP workflow と email-agent skill を使用する108件のケースからなる WhisperBench を導入しました。その attack framework である MemGhost は、runtime feedback なしに1つの email payload を生成します。成功には、agent が poisoned memory を採用し、直後の response でユーザーに alert せず、後の behavior を変更することが必要です。

56件の held-out case について、この論文は GPT-5.4 を使用した OpenClaw で87.5%、Sonnet 4.6 を使用した Claude Code SDK で71.4%の end-to-end success を報告しています。

これらの数値は、著者らの benchmark、proxy environment、reward design、model version に属するものです。評価は message が inbox に到達した後から開始されます。spam filtering、SPF、DKIM、DMARC などの mail-provider controls は model 化されていません。この論文は first-version preprint であるため、結果には replication が必要です。

なぜ write-time filtering だけでは不十分なのか

Write gate は、提案されたレコードと、その時点で利用可能な evidence を確認します。しかし、将来の task、隣接して retrieval される他のレコード、または agent が後で呼び出す tool は確認できない可能性があります。

これにより、4つの blind spot が生じます。

Write-time checks は依然として重要です。永続化される unsafe state の量を減らします。問題は、storage approval を恒久的な trust とみなすことです。

Retrieval は authority ではなく、candidate context を返すべきです。レコードを model context に挿入する前に、system は source、age、task relevance、contradictions、sensitivity、requested effect を確認できます。高リスクのレコードは withheld、summarized、または review に回すことができます。Microsoft の現在の guidance は、この write-and-retrieval split に加え、deterministic isolation と full lifecycle visibility を推奨しています。Microsoft Learn

secure agent-memory architecture

System には、source から action まで追跡可能な chain が必要です。

`source → write decision → stored version → retrieval decision → model context → policy decision → tool result`

*Caption: memory record は write と retrieval の checks を通過した後にのみ candidate context になります。Independent policy は引き続きすべての consequential action を authorize し、influence chain は investigation と rollback を支援します。*

1. Durable write には明示的な intent を要求する

すべての message、document、tool response を long-term memory にしてはいけません。どの event が durable state を作成できるかを定義してください。ユーザーが確認した preference や明示的な「これを覚えておいて」という action は、信頼できない attachment の autonomous summary よりも正当化しやすいものです。

誰または何が write を要求したかを記録してください。tool または subagent が開始した場合、その identity を保持し、すべてを end user の名前にまとめないでください。

2. Record とともに provenance、scope、expiry を保存する

有用な memory record に必要なのは、text と embedding だけではありません。少なくとも以下を保存してください。

Signature は record integrity を保護できます。しかし、元の content が true、safe、authorized だったことを証明するものではありません。

3. Code と storage で isolation を強制する

Tenant、user、agent、workspace の境界は、access-control list、scoped token、row-level policy、encryption boundary に組み込むべきです。Prompt instruction は access control ではありません。Shared memory は、便利な default namespace ではなく、named writer と reader を持つ明示的な product feature にすべきです。

4. Low-trust write を quarantine する

「discarded」と「trusted memory」の間に state を作成してください。External file、email、web page、indirect tool output、intent が不明確なレコードは quarantine に入れることができます。Deterministic rule または authorized reviewer が promote するまで、通常の retrieval に表示されるべきではありません。

Quarantine は、影響を継続させることなく incident responder が evidence を保存する場所にもなります。

5. Retrieval 時にレコードを再評価する

Retrieval risk は現在の task に依存します。各レコードだけでなく、選択された set を評価してください。

6. Tool authorization を独立させる

Memory は parameters を提供してもかまいません。しかし、permissions を拡張してはいけません。Tool gateway は、current identity、allowed action、resource boundary、destination、budget、approval requirement を強制する必要があります。Memory 由来の arguments は untrusted input として扱い、current policy に照らして validate してください。

Human approval にも fresh context が必要です。提案された action、影響を受ける resource、data destination、そして影響を与えた memories を表示してください。その chain なしに「Approve?」と尋ねると、関連する decision が隠れてしまいます。

7. Influence をログに記録し、rollback を支援する

Memory の create、read、update、delete operation を identity と provenance 付きでログに記録してください。Consequential action については、context に注入されたレコードの ID と version を保持します。これにより、次の3つの incident question に答えられます。

Deletion は、UI 上の row を隠すだけでなく、active influence を除去する必要があります。Index、summary、cache、replica、derived record をテストしてください。OWASP の agent guidance は、validated and isolated memory、adversarial test、release evidence を推奨しています。また、より広範な memory analysis では、persistent prompt injection を agent-memory threat surface に位置付けています。OWASP Agent Security Cheat Sheet OWASP GenAI Security Project

memory class ごとに policy を選ぶ

1つの retention policy では粗すぎます。write と retrieval の rule が異なる class から始めてください。

この table は starting policy であり、compliance claim ではありません。Medical agent、coding assistant、sales agent、personal assistant では harm model が異なります。不変条件はより限定的です。Persistence によって、untrusted content が permission へと暗黙に変換されてはいけません。

再現可能な memory-poisoning test workflow

Test harness は benign marker と disposable account を中心に構築してください。Persistence と policy failure を検出するために、real credential や exfiltration payload は必要ありません。

Step 1: Clean baseline を取得する

Memory store を空にして、固定された task set を実行します。Answer、retrieval result、tool proposal、policy decision、latency、user-visible explanation を記録してください。System change と通常の model variance を区別できるよう、十分な回数を繰り返します。

Step 2: Paired clean case と poisoned case を定義する

各 case では user task を一定に保ち、candidate memory path だけを変更します。少なくとも以下を対象にしてください。

`TEST_BLOCKED` を disposable log に書き込むなど、canary action を使用してください。期待される policy path の外部で agent がその action を実行または提案した場合、test は失敗です。

Step 3: すべての boundary を観測する

4つの outcome を個別に取得します。

End-to-end pass は、弱い layer を隠す可能性があります。たとえば authorization が canary action を block していても、poisoned record が保存され、繰り返し retrieval されている可能性があります。これは有用な containment ですが、memory defect には依然として修正が必要です。

Step 4: Utility と false positive を測定する

同じ pipeline で benign memory case を実行します。Task completion、accepted user preference、incorrect quarantine、retrieval precision、latency、review volume を追跡してください。すべての durable memory を block する filter は、feature を削除したため attack success が低くなっているだけです。

Step 5: Risk に応じて release gate を設定する

有用な gate には以下が含まれます。

OWASP の open-source Agent Memory Guard project は、memory scanning と test tooling に関する1つの implementation signal です。その repository と self-reported evaluation は、team が pattern を調査する助けになりますが、実際の agent、model、memory backend、policy stack をテストする代替にはなりません。

Memory extraction、summarization、embedding、retrieval、prompt、model、tool schema、authorization、deletion logic に変更を加えた後は、test suite を再実行してください。これらの layer は相互に作用します。

証拠が支持すること、支持しないこと

論文は、構築された benchmark 内での attack success を測定しました。Production における AI agent memory poisoning の population-wide rate は測定していません。

論文が支持する結論は、次の3つに限定されます。

論文は、memory governance に context-sensitive defense が必要だと推論しています。Microsoft と OWASP は独立して、write、isolation、retrieval、user control、observability、testing にまたがる defense in depth を推奨しています。

実務的な解釈は、すべての transition を testable にすることです。Team は、なぜ record が保存されたのか、なぜ retrieval されたのか、どのように action に影響したのか、どの policy がその action を authorize したのか、そして record の downstream effect をどのように除去するのかを説明できるべきです。

チームからよく寄せられる質問

AI agent memory poisoning は prompt injection と同じですか？

いいえ。Prompt injection は hostile instruction を導入する1つの方法です。Memory poisoning は persistence を加えます。操作された content が保存され、後の context で retrieval され、元の input が消えた後も future reasoning または tool use に影響する可能性があります。

Signed memory record は poisoning を防げますか？

いいえ。Signature は、作成後に record が改変されていないことを証明できます。しかし、元の content が true、safe、authorized だったことは証明できません。Secure design には、provenance、explicit write intent、scope、expiry、retrieval checks、independent action authorization も必要です。

Memory poisoning defense は write time と retrieval time のどちらで実行すべきですか？

両方です。Write gate は unsafe persistence を減らします。Retrieval check は、個々の record が保存された時点では見えなかった stale、contradictory、compositional、trigger-dependent risk を検出します。どちらの layer も tool authority を付与できないようにすべきです。

主張の確認

Sources