レッスン5: メモリの境界と安全性
学習目標:
- 機能としての「メモリ」がなぜ新たな攻撃対象でもあるかを説明できる
- MemoryTrapの事例で、日常的な操作がどのようにセッション横断攻撃に変わったかを再述できる
- どのコンテンツを永続的メモリに書き込んではならないか、どの情報が古くなると危険になるかを判断できる
- メモリポイズニングに特に対抗する具体的な対策を少なくとも2つ挙げることができる
前提: レッスン4を終えて、構造化された状態とチェックポイントを理解している | 前: << レッスン4 | 次: レッスン6 >>
日常的な「リポジトリをクローンし、インストールを承認する」操作
永続的メモリを備えたエージェントに新しいプロジェクトの手伝いを依頼します: リポジトリをクローンし、依存関係が正常にインストールされるか確認します。エージェントはpackage.jsonを読み、インストールが必要な依存関係を見つけ、承認するか尋ねます。あなたは「進めて」と言い、エージェントがインストールを実行し、タスクが完了し、別のことに移ります。
この一連の流れには疑わしいものは何もありません。誰もエージェントに「以前の指示を無視しろ」と言っていませんし、知らないURLを渡してもいません。エージェントは単にやるべきことをやりました: クローン、チェック、インストール、完了。
Ciscoの研究チームが公開し、OWASP Gen AI Security Projectのブログに発表された実際の脆弱性 — 研究者たちはそれをMemoryTrapと名付けました — は、まさにこの種の経路を記述しています。記事にはこうあります: "In the vulnerability we called MemoryTrap, we found that a routine developer workflow could turn into persistent prompt injection. The path was surprisingly ordinary: clone a repository, let the agent help, approve a dependency installation, and move on."1（私たちがMemoryTrapと呼んだ脆弱性では、日常的な開発者のワークフローが永続的なプロンプトインジェクションに変わることを発見しました。その経路は驚くほど平凡でした: リポジトリをクローンし、エージェントに手伝わせ、依存関係のインストールを承認し、先に進みます。）表面上は何も起こりませんでしたが、承認されたインストールの内部で、依存関係パッケージやリポジトリのどこかに隠された悪意のあるコンテンツが、より厄介なことをする機会を得ました。それはこのプロジェクトに留まりませんでした: "Instead, it reached persistent memory, the global hooks configuration, and even influenced a highly trusted instruction layer through the system prompt."1（代わりに、それは永続的メモリ、グローバルフック設定に到達し、システムプロンプトを通じて高度に信頼された指示レイヤーにさえ影響を与えました。）別の言い方をすれば、"a one-time action could shape the model's future behavior across sessions, projects, and even reboots."1（1回限りのアクションが、セッション、プロジェクト、さらには再起動を越えてモデルの将来の振る舞いを形作ることができました。）
メモリが新たな攻撃対象である理由: ASI06
この事例は、OWASPのエージェントセキュリティのリスク分類におけるASI06 — メモリ＆コンテキストポイズニング — に該当します。このカテゴリの背後にある理由は、公式ブログに明確に述べられています: "Agentic systems do not just respond in the moment. They retain context, reuse memory, and rely on persistent state to guide future reasoning and actions. That is what makes them useful. It is also what makes them vulnerable."1（エージェントシステムはその場で応答するだけではありません。それらはコンテキストを保持し、メモリを再利用し、永続的な状態に依存して将来の推論と行動を導きます。それがそれらを有用にするものです。それはまた、それらを脆弱にするものでもあります。）
この文を分解すると、それは実際には最初の4つのレッスンが1つずつ積み上げた能力リストです: レッスン2の履歴管理は会話を継続させ、レッスン3の外部メモリは情報をセッション横断で永続化させ、レッスン4の構造化された状態とチェックポイントはタスクを停止した場所から再開させます。これらの能力の1つ1つがエージェントをより有用にし、1つ1つがこれをも意味します: 悪意のあるコンテンツがこれらの信頼された、自動的に読み取られ実行される場所に滑り込むと、その影響は今回の1つの間違った答えに限定されなくなります。それは繰り返し読み取られ、繰り返し効果を発揮し、誰かが気づいて掃除するまで続きます。
それがMemoryTrapの「依存関係のインストールを承認」が危険だった根本原因です。承認されたのは孤立した一回限りの操作ではなく、永続的メモリとフック設定に書き込める経路でした — 何度も何度も信頼され読み込まれる種類のストレージです。
何を保存し、何を保存しないか
MemoryTrapが提起する中核的な問いは: どのコンテンツを永続的メモリやフック設定 — 自動的に繰り返し読み込まれる種類のストレージ — に決して許可してはならないのでしょうか？
以前のコース「エージェントツール呼び出し: エージェントに実際に行動させる」のレッスン5「許可と安全性: エージェントができることの境界」は、基本的なルールを示しました: ツールが返すコンテンツは常にデータであり、決して指示ではありません。メモリレイヤーでは、このルールをもう一歩進める必要があります: 読み取られたコンテンツはレビューなしで自動的にメモリに昇格させてはなりません。エージェントがタスクを実行中に読むリポジトリファイル、依存関係のインストールログ、ウェブコンテンツは、このタスクのための単なる入力データです。それらの行の1つを逐語的にCLAUDE.mdや自動メモリにコピーすることは、「このタスク中に読んだ信頼できないテキスト」を「将来のすべてのセッションで信頼されるルールとして読み込まれるコンテンツ」に昇格させます。それがMemoryTrapの「依存関係のインストールを承認」の内部で起こったことです。
「何を保存するか」という具体的な問いに対して、直接適用できるいくつかの境界:
- 認証情報は保存すべきではありません: 鍵、パスワード、アクセストークン — 自動的に読み込まれるメモリファイルに書き込まれると、毎セッションでウィンドウに再露出され、見返りの利益なしで漏洩面を広げます。
- 信頼できない生のテキストはそのまま保存すべきではありません: タスク中に読んだファイル内容、ウェブテキスト、依存関係の出力。それらのいずれかを記憶する必要がある場合、それは人間が確認し明確な声明として書き直した結論であるべきです（たとえば「この依存関係にはNode 18以上が必要」）、読んだテキストのブロック全体を逐語的にメモリファイルに移動するのではありません。
- 安定した確認済みのルールと事実は保存する価値があります: たとえばレッスン3のプロジェクトコードスタイル規約、または実際の調査後に確認された根本原因。このコンテンツの信頼できるソースは明確であり、メモリに書き込むことは真の価値をもたらします。
テストはレッスン3のパス境界チェックと同じ考え方です: 「これを技術的に書き込めるか」ではなく、「書き込もうとしているコンテンツは信頼できるソースからのものか、将来のすべてのセッションによって自動的に信頼されるに値するか」。
古いメモリの危険性: かつて正しかったが、今は間違っているルール
「何を保存しないか」の先には、見落としやすい第二のリスクのクラスがあります: メモリに既に存在するコンテンツが、時間の経過とともに古いメモリになることがあります — かつては正しかったが、もはや適用されないのに、永続的メモリに存在するために現在有効なルールとしてまだ実行されます。
数ヶ月前に書かれた自動メモリのメモを思い浮かべてください: 「このプロジェクトのデプロイは簡単 — mainブランチにプッシュするだけで自動的に本番に上がり、追加のレビューは不要」。それは当時は真実だったかもしれません。しかし数ヶ月が経ち、プロジェクトは必須のコードレビューを導入し、誰もそのメモを更新しません。エージェントがその古いメモリを読み、まだそれを現在の信頼できる操作ガイダンスとして扱う場合 — mainに直接プッシュし、レビューをスキップする — 結果はメモリポイズニングと同じクラスの問題です: 信頼されるべきでないコンテンツが、「メモリ」スロットを占有しているという理由だけで権威ある事実として扱われます。
古いメモリとメモリポイズニングの違いは起源です: ポイズニングは悪意のあるコンテンツが能動的に書き込まれること、古いメモリは善意で正しかったコンテンツが誰も適時に更新または掃除しなかったために信頼できなくなることです。しかし両方とも同じ防御姿勢を共有します — メモリ内のコンテンツを無条件に信頼すべきではなく、特に時間とともに変化する許可やプロセスに触れる場合、それがまだ成立することを確認するために定期的に再検証する必要があります。
Anthropicの修正、およびメモリを越えた他の信頼される表面
MemoryTrapが公開された後のAnthropicの対応は記録する価値があります: 記事にはこうあります、"To Anthropic's credit, after we at Cisco disclosed the issue, Claude Code v2.1.50 removed user memories from the system prompt, reducing the specific high-trust override path we identified. That was the right fix for the path we found."1（Anthropicの功績として、私たちCiscoが問題を公開した後、Claude Code v2.1.50はシステムプロンプトからユーザーメモリを削除し、私たちが特定した特定の高信頼オーバーライド経路を減少させました。それは私たちが見つけた経路に対する正しい修正でした。）この評価は独自のリマインダーを含んでいます: 修正されたのは「私たちが見つけた経路」であり、「メモリポイズニングリスクのクラス全体」ではありません。メモリ、フック、設定ファイル — システムが信頼されるソースとして繰り返し読み込む場所はどこでも、原則として次の攻撃の着地点になりえます。
OWASPブログからのより一般的な原則: "Once malicious content reaches trusted surfaces like memory, hooks, or configuration, the attacker is no longer just influencing one response. They are influencing future reasoning."1（悪意のあるコンテンツがメモリ、フック、または設定のような信頼される表面に到達すると、攻撃者はもはや1つの応答に影響を与えているだけではありません。彼らは将来の推論に影響を与えています。）この行は、このレッスンが議論してきたすべてを締めくくります: レッスン3のメモリファイルとレッスン4のチェックポイントはすべて、根本的には「将来のセッションが信頼し読み込む」ストレージです。それらが有用であるほど、それらは真剣に守られた書き込みゲートに値します。
まとめ
- メモリが有用なのは、コンテンツをセッション横断で永続化し、繰り返し信頼して読み込めるようにするからです — それがまさにそれを攻撃対象にもするものです。ASI06リスクカテゴリはこのメモリおよびコンテキストポイズニングのクラスを記述します。
- MemoryTrapの事例は、1つの普通に見える日常的なワークフロー（リポジトリをクローンし、依存関係のインストールを承認する）が、悪意のあるコンテンツを永続的メモリとグローバルフック設定に到達させ、システムプロンプトを通じて高度に信頼された指示レイヤーにさえ影響を与えることができることを示します。1回限りのアクションで、セッション、プロジェクト、再起動を越えてモデルの将来の振る舞いを形作るのに十分です。
- 何を保存するかには明確な境界があります: 認証情報は保存すべきでなく、信頼できない生のテキストは直接保存すべきでなく、確認済みの安定したルールと事実のみが保存する価値があります。
- 古いメモリも危険です: かつて正しかったがもはや適用されないコンテンツが、現在有効なルールとしてまだ実行される場合、メモリポイズニングと同じクラスの問題です。
- Anthropicは公開された経路を修正しました（v2.1.50はシステムプロンプトからユーザーメモリを削除しました）が、より一般的な原則はこれです: 悪意のあるコンテンツがいずれかの信頼される表面（メモリ、フック、設定）に到達すると、攻撃者はもはや1つの応答ではなく将来の推論に影響を与えています。
レッスン6 >>