Distributed Attacks in Persistent-State AI: AIエージェント実装の詰まりどころ

description: AIコーディングエージェントがセッションをまたいでコードベースを保持するようになった今、永続状態を悪用した分散攻撃という新たな脅威面が浮上しています。実装上の論点と対策の考え方を整理します。

meta description: 永続状態を持つAIエージェントへの分散攻撃（Distributed Attacks in Persistent-State AI）の仕組みと、tool use・MCP実装における具体的なリスク管理の観点を解説します。

---

何が出たのか

2026年7月初旬、Hacker NewsおよびRedditのr/MachineLearningで「Distributed Attacks in Persistent-State AI Control」に関する議論が活発化しています。発端は、AIコーディングエージェントがセッションをまたいでコードベースを保持する運用が一般化してきたことへの懸念です。

具体的には、エージェントが複数セッションにわたってファイルシステムやデータベース、外部APIの認証情報を「記憶」しながら反復的にコードを出荷（ship）するようになった結果、単一セッション完結型の従来モデルでは想定されていなかった攻撃面が生まれているという指摘です。

議論の中心にあるのは次の2点です。まず、プロンプトインジェクション（外部入力を通じてエージェントの指示を書き換える攻撃）がセッションをまたいで効果を持続できるようになった点。次に、単一の悪意ある入力ではなく、複数の小さな操作を時間差で組み合わせる「分散型」の攻撃パターンが現実的な脅威として認識されつつある点です。

Hugging Faceのフォーラムでも、MCPサーバー（Model Context Protocol：エージェントがツールや外部リソースにアクセスするための標準プロトコル）を経由したツール呼び出しのログ管理が不十分な実装事例が複数報告されており、実装コミュニティ全体で問題意識が高まっています。

---

技術的に面白い点

この問題が技術的に興味深いのは、攻撃の「単位」が変わった点にあります。

従来のプロンプトインジェクションは、1回のリクエスト・レスポンスのサイクル内で完結するものがほとんどでした。エージェントがステートレス（状態を持たない）であれば、悪意ある入力の影響はそのセッションで終わります。

ところが、永続状態を持つエージェントでは話が変わります。たとえば次のようなシナリオが成立します。

1. 1.ステップ1（無害に見える操作）: エージェントがリポジトリのREADMEを読み込む際、攻撃者が仕込んだ隠しコメントが「次回のコード生成時にはこのパターンを優先せよ」という指示を含んでいる
2. 2.ステップ2（状態への書き込み）: エージェントがその指示をメモリ（長期記憶ストア）に保存する
3. 3.ステップ3（後続セッションでの発火）: 別のセッションで別のユーザーがエージェントに依頼した際、保存された指示が参照され、意図しないコードが生成・コミットされる

この「時間差で分散した操作の組み合わせ」が検知を難しくしています。各ステップを単独で見ると正常な動作に見えるため、ルールベースのフィルタリングでは捕捉しにくいのです。

さらに、MCP経由でエージェントが複数のツール（ファイル操作、Git操作、外部API呼び出しなど）を組み合わせて使う場合、各ツール呼び出しの権限スコープが適切に分離されていないと、一つのツールで得た情報を別のツールへの入力として流用する「権限の横断」が起きやすくなります。

---

既存の流れとの違い

これまでのAIエージェントのセキュリティ議論は、主に「単一セッション内のプロンプトインジェクション対策」と「出力のサニタイズ（無害化処理）」に集中していました。LangChainやLlamaIndexといったフレームワークが提供するガードレールも、基本的にはリクエスト単位での入出力検査を前提としています。

今回の議論が既存の流れと異なるのは、攻撃の時間軸と状態の永続性を明示的に脅威モデルに組み込む必要性を提起している点です。

具体的な差分を整理すると以下のようになります。

MCPの普及によってエージェントが扱えるツールの種類と数が増えた結果、「何がどのセッションで実行されたか」のトレーサビリティ（追跡可能性）が従来以上に重要になっています。OpenAIのResponses APIやAnthropicのTool Useも、ツール呼び出しのログ構造を持っていますが、複数セッションをまたいだ状態変化の監査ログとして十分かどうかは実装側の設計に依存します。

---

エージェント実装で詰まりやすい点

実際にプロダクトや業務システムにAIエージェントを組み込む際、この問題はどこで顕在化しやすいかを整理します。

メモリストアの設計

エージェントに長期記憶を持たせる実装では、何をメモリに書き込むかのフィルタリングが必要です。LangChainのMemorySaverやカスタムのベクトルDB（pgvectorなど）を使う場合、書き込み前に「この情報はエージェント自身の判断で生成されたものか、外部入力由来か」を区別するロジックが求められます。外部入力由来の情報をそのままメモリに保存すると、前述の時間差攻撃の起点になります。

• 書き込みポリシーの明示化メモリへの書き込みをエージェントの自律判断に任せず、書き込み可能なカテゴリをスキーマで定義しておくことが有効です。

tool useの権限スコープ

MCPサーバーを介してファイル操作やシェル実行を許可する場合、ツールごとに権限スコープを最小化する設計が基本です。しかし実装上は、開発速度を優先して広めの権限を与えたままになるケースが多く見られます。

• 最小権限の原則の徹底ツール定義の段階で読み取り専用・書き込み可能・実行可能を明示し、エージェントが自己判断で権限を拡張できない構造にします。MCPのツール定義ファイルにスコープを記述し、サーバー側で強制するのが現実的です。

ログと監査の設計

エージェントが複数セッションにわたって動作する場合、「どのセッションで何のツールを呼び出し、状態をどう変化させたか」を後から追跡できるログ設計が必要です。現状のLLMプロバイダーのAPIログは、リクエスト・レスポンスのペアを記録しますが、状態変化の差分（diffベースのログ）は別途実装する必要があります。

• セッションIDと状態スナップショットの紐付け各セッション開始時と終了時に状態のスナップショットを取り、セッションIDと紐付けて保存する設計が、インシデント発生時の調査を大幅に簡略化します。

fallbackとロールバックの設計

エージェントが意図しないコードをコミットした場合や、外部APIに意図しないリクエストを送信した場合の復旧手順を事前に設計しておく必要があります。Gitを使うコーディングエージェントであれば、エージェントが操作するブランチを隔離し、人間のレビューを経てからマージする構成が現実的です。

• エージェント専用ブランチの隔離エージェントの書き込みをmainブランチに直接反映させず、PRベースのレビューフローを挟む構成は、分散攻撃の影響範囲を限定する上でも有効です。

推論コストとセキュリティチェックのトレードオフ

入出力の検査を強化するほど、追加のLLM呼び出しや検査処理が発生し、レイテンシとコストが増加します。すべての入力を別モデルで検査する構成は理想的ですが、リアルタイム性が求められるユースケースでは現実的でないことがあります。検査の粒度と頻度をユースケースのリスクレベルに応じて設計することが求められます。

---

Spectralの見解

1. 技術的な読み

Persistent-State AIへの分散攻撃は、現時点では「理論的に成立するシナリオ」の段階ですが、AIコーディングエージェントの実運用が広がるにつれて、実害が報告されるまでの時間は短くなると見ています。特にMCPの普及によってツールの接続が容易になった分、権限設計の甘さが表面化しやすい環境になっています。エージェントの「自律性の高さ」と「状態の永続性」が組み合わさった実装では、セキュリティ設計をアーキテクチャの初期段階から組み込む必要があります。後付けで対策を追加する構造は、ツール間の依存関係が複雑化した後では修正コストが高くなります。

2. PoCで確認すべき点

PoCの段階では、機能の動作確認と並行して以下を検証することを推奨します。まず、外部入力（ファイル、API応答、ユーザー入力）がメモリストアに書き込まれる経路を洗い出し、意図しない書き込みが発生しないかを確認します。次に、MCPツールの権限スコープが実際の動作と一致しているかをログで検証します。最後に、エージェントが複数セッションにわたって動作した際の状態変化を追跡できるログが取れているかを確認します。この3点が担保できていない場合、本番移行後のインシデント対応が困難になります。

3. 業務・プロダクト実装に移す時のリスク

業務システムへの組み込みで最も注意が必要なのは、エージェントが操作できるリソースの範囲が開発時の想定より広がりやすい点です。特に、既存の社内システムとMCP経由で接続する場合、ツール定義の権限スコープが社内システムのアクセス制御と整合しているかを確認する工程が必要です。また、エージェントの動作ログを誰がどのように監査するかの運用設計がないまま本番稼働すると、異常検知が遅れるリスクがあります。意思決定者の視点では、「エージェントが何をしたか」を後から説明できる体制を整えることが、社内承認と対外的な説明責任の両面で重要になります。

---

まとめ

AIコーディングエージェントがセッションをまたいで状態を保持するようになったことで、単一セッション完結型の脅威モデルでは捕捉できない分散攻撃のリスクが現実的な課題として浮上しています。

技術的な対応の核心は、メモリへの書き込みポリシーの明示化、ツールの最小権限設計、状態変化の差分ログ、エージェント専用ブランチによる影響範囲の限定の4点に集約されます。これらはいずれも、エージェントの機能設計と並行して初期アーキテクチャの段階で組み込む必要があります。

MCP経由のtool useが標準化されつつある現在、エージェントの「できること」が増えるほど、権限とログの設計が実装品質を左右します。機能の動作確認と同じ粒度で、状態管理とセキュリティの検証をPoCに組み込むことが、本番移行後のリスクを抑える上で有効です。

---

*Spectralでは、AIエージェントの設計・PoC・本番移行を支援しています。tool useやMCPの権限設計、ログ・監査の実装方針についてご相談があればお気軽にお問い合わせください。*

関連論点として Is Spec Driven Development with AI agents the: AIエージェント実装の詰まりどころ もあわせて読むと、この技術動向の背景を追いやすくなります。

Spectralでは、技術調査からPoC設計、プロダクト実装まで支援しています。実現性の確認や事業活用の相談は サービス詳細 と お問い合わせ をご覧ください。