9月3日、The Newsが「AI agents can hide memory attacks until it's too late」と題した記事を公開した。この記事では、メモリを持つAIエージェントへの攻撃が検知される前に長期間潜伏できるという研究成果について詳しく紹介されている。なお、元記事はパキスタンの一般紙による報道であり、カルガリー大学の研究を二次的に伝えたものである。

「何も起きていない」＝「安全」ではない

カルガリー大学の研究チームが（The News報道によれば）、メモリ搭載AIエージェントに対して2,614件の攻撃シーケンスをシミュレーションした。その結果、一部の攻撃は被害が進行し始めた後も、外部から目に見える痕跡を残さないことが判明した。

研究をリードしたのはHadis Karimipour氏ら。調査対象となった攻撃手法は以下の4種類だ。

• Chain Poisoning（連鎖汚染）：エージェントの推論ステップに偽情報を埋め込み、後続の判断を誤らせる手法。いわばプロンプトインジェクションの「記憶経由版」ともいえる
• Policy Rewriting（ポリシー書き換え）：エージェントが参照する行動指針や制約条件そのものを改ざんし、意図しない振る舞いを恒久化する
• Backdoor Triggering（バックドアトリガー）：通常時は正常に動作しつつ、特定の入力条件や文脈が揃ったときだけ悪意ある挙動が発動する。従来のバックドア攻撃のAIエージェント版といえる
• Slow Drift（緩やかな漂流）：一度に大きな変化を起こすのではなく、複数セッションをまたいで徐々に振る舞いをずらしていく手法。単発の監査では異常として検知されにくい

なぜメモリが攻撃面になるのか

現代のAIエージェントは、複数セッションにまたがってデータを保持し、マルチフェーズのタスクをこなし、外部ツールを活用できる。この「記憶」こそが有用性の源泉だが、同時に攻撃面でもある。

偽情報がメモリに書き込まれると、エージェントはそれを「自分が学習した事実」として扱う。従来のサイバー攻撃——悪意あるリンクのクリック、マルウェアの実行、パスワード窃取——は発動とほぼ同時に検知できる。メモリへの汚染はそうではない。 エージェントは何日も、あるいは複数セッションにわたって正常に動作し続け、汚染されたメモリが参照された瞬間に初めて問題が顕在化する。

この構図は、プロンプトインジェクション攻撃の研究文脈とも重なる。OWASP LLM Top 10でもインジェクション系の脅威は最上位に位置づけられており、メモリ経由の汚染はその発展形とみなせる。

研究チームが特に問題視したのが、Slow DriftとBackdoor Triggeringだ。これらは「汚染されたメモリが使われるまで」検知がほぼ不可能なまま潜伏する。

「今すぐテストして問題なければ安全」という前提が崩れる

さらに厄介なのは、リスクが単調に増加しないという点だ。研究チームは「非単調（non-monotonic）なパターン」を報告している。ある時点では攻撃が深刻に見え、別の時点では軽微に見え、その後に本格的に展開するというパターンだ。

これは一般的なセキュリティプラクティスを根底から揺さぶる。多くの現場では「不審なインプットにさらした直後にテストして問題なければ安全」とみなす。研究チームはこれを「偽の記述がノートに書かれた直後に確認するが、誰もそれに基づいて行動する前の段階」に例える。即座に被害が出ないことは、安全の証明にはならない。

エンジニア・CTOへの含意

AIエージェントにメモリ機能を実装する、あるいはすでに運用している組織にとって、この研究は実装判断に直結する。「直後の動作確認」だけでは不十分であり、複数セッションにわたる継続的なモニタリングと、メモリの内容そのものの監査が必要になる。汚染の検知タイミングが非線形である以上、単発のスナップショット評価では見逃しが発生する。

具体的な対策の方向性としては、以下のようなアプローチが考えられる。

• メモリの読み書きログを全件保存し、セッションをまたいで差分を追跡する（いわゆるメモリ監査）。LangChainやLlamaIndexなどエージェントフレームワークは独自のメモリ実装を持つため、それぞれのAPI仕様に沿ったフック設計が求められる
• 外部メモリストア（ベクトルDBなど）への書き込み権限を最小化し、書き込み操作に承認フローを挟む。最小権限の原則をエージェントのメモリ層にも適用する発想だ
• 定期的なメモリスナップショット比較によるドリフト検出。Slow Driftのような緩慢な変化は、直近のスナップショットとの差分比較よりも、より長期のベースラインとの比較が有効とされる
• AI固有のリスク管理フレームワークとして、NIST AI RMFやMITREのATLAS（AIシステムへの敵対的攻撃を体系化したナレッジベース）が参照軸になりうる。特にATLASはLLMエージェントへの攻撃手法をTACTICSレベルで整理しており、今回の研究で挙げられた手法との対応を確認する価値がある

※編集部の考察：本記事で紹介した手法はいずれも「AIエージェントが記憶を持つ」という設計前提に起因する。メモリレス設計への回帰が現実的でない本番ユースケースほど、上記のような監査・権限制御の仕組みを設計段階から組み込む必要がある。

詳細はAI agents can hide memory attacks until it's too lateを参照していただきたい。