7月24日、Auth0が「Agentic Loops and Agent Graphs: Security Risks You Need to Know」と題した記事を公開した。AIエージェントのセキュリティ議論は「モデルが安全か」に集中しがちだが、この記事が問うのはその一段上の話だ。実際の被害範囲（blast radius）を決めるのはモデルではなく、その周囲のアーキテクチャである——エージェントをループで動かすか、マルチエージェントグラフを使うかという設計判断こそが、インシデントの深刻度を左右する。

エージェントループとは何か

通常のLLM呼び出しは「プロンプト入力→レスポンス出力」の1往復だ。これに対しエージェントループは「考える→ツールを使う→結果を観察する→また考える」を繰り返す反復実行サイクルである。この仕組みにより、ウェブ検索・コード生成・テスト実行・チケット起票といった複数ステップのタスクを連続して処理できる。

AIエージェント研究で知られるSimon Willisonは、エージェントを「目標を達成するためにツールをループで実行するもの」と定義している。シンプルな定義だが、このループという構造が後述するセキュリティ上の問題を生む本質でもある。

エージェントグラフとは何か

エージェントグラフは、複数のエージェントをノード、コミュニケーションや委譲関係をエッジとして表現したマルチエージェントシステムだ。オーケストレーターエージェントがタスクを受け取り、分割して専門サブエージェントに委譲し、出力を収集する。LangGraphはこのパターンを明示的にモデル化したフレームワークの代表例である。

本当に必要か？

記事はここで「多くの場合、不要だ」と率直に述べている。

コンテキストウィンドウに収まるタスクなら、ループはレイテンシ・コスト・障害ポイントを増やすだけだ。Extended thinking（思考プロセス拡張）モデルはモデル内部で反復推論を行えるため、ループを自前でオーケストレーションしなくても多段推論が可能になっている。

マルチエージェントグラフは特に過剰設計になりやすい。データが示す傾向として、並列化できるタスクでは有効だが、逐次タスクでは有害になる。そして大半のタスクは逐次的だ。

「複雑なアーキテクチャは作っていて面白いので、開発者はそちらへ偏りがちだ」と記事は指摘する。整理されたLLM呼び出し1回で解決できる問題は、思っているより多い。

ループがセキュリティに与える影響

ループの価値は自律性にある。そしてそれが危険の源でもある。

プロンプトインジェクションが反復ごとに蓄積される。 シングルターン呼び出しでは、悪意あるペイロードが操作できるのはその1回のレスポンスだけだ。しかしループでは、エージェントが外部ソース（ウェブサイト、ドキュメント、APIレスポンス）を読み込み、その結果を毎回コンテキストに戻す。ツール呼び出しのたびに攻撃者制御のテキストが推論に再混入する機会が生まれる。

取り消し不能なアクションが積み重なる。 ループがメール送信・APIコール・フォーム送信を実行するのは、人間が全実行履歴を確認する前だ。問題に気づいたとき、すでに複数のアクションが巻き戻せない状態になっている。

蓄積されたコンテキストが攻撃面になる。 長いループの序盤で埋め込まれた誤った前提は、以降のステップに持続的に影響する。これはシングルターンの注入とは異なり、ゆっくりと静かに推論全体に広がる。

グラフがセキュリティに与える影響

グラフは別クラスの問題を生む。エージェントAの出力がエージェントBの入力になるとき、Aの侵害はすべての下流に伝播する。

2024年の論文「Prompt Infection: LLM-to-LLM Prompt Injection within Multi-Agent Systems」は、1つの注入プロンプトが接続されたエージェントネットワーク全体に自己複製できることを実証した。各感染エージェントが攻撃者の命令を実行しながら、次のエージェントへ悪意あるプロンプトを伝播させる。

対策

記事が提示する具体的な対策は以下の4点だ。

1. ループを封じ込める。
ステップ数上限・時間制限を設ける。「ユーザーへの確認」をfallbackではなく正規の出力として設計する。取り消し不能なアクションには明示的な承認ゲートを置く。有効なパターンとして記事が挙げるのがCIBAベースの非同期認可だ。CIBAとは「Client-Initiated Backchannel Authentication」の略で、金融や医療などの分野でユーザーが別デバイス（スマートフォンなど）から取引を承認する仕組みとして標準化されてきた認証フローである。これをエージェントに応用すると、高インパクトなアクションをエージェントが単独で実行せず、ユーザーの明示的な承認を非同期に待つ設計が実現できる。自律性を損なわずに人間の制御を差し込む点で、エージェントセキュリティと相性が良い。

2. ツールの権限をタスクにスコープする。
注入が成功したときの被害範囲は、エージェントが持つ権限に比例する。タスク単位の認可（権限を短命なタスクIDにスコープし、完了時に削除）で横展開を制限できる。

3. ツール出力を信頼しない。
ループ中に外部ソースから読み込んだデータは、コンテキストに戻す前に検証する。これはOWASPのLLM05（不適切な出力処理）が指摘するポイントでもある。LLMアプリケーション向けのOWASPトップ10は、AIセキュリティの共通参照先として広く参照されている。

4. マルチエージェント委譲をトラスト境界として扱う。
オーケストレーターからサブエージェントへの権限継承を明示的なスコーピングなしに行わない。エージェント間メッセージの発信元を検証し、委譲チェーン全体をログに残す。ループの封じ込めと組み合わせることで、感染が下流のエージェントに連鎖するリスクを構造的に抑えられる。

記事の結論は明快だ。「プロンプトインジェクションを100%防ぐことはできないかもしれない。しかし注入が成功したときの被害範囲を決めるのは、ほぼすべてモデルではなくアーキテクチャだ」。

詳細はAgentic Loops and Agent Graphs: Security Risks You Need to Knowを参照していただきたい。