フレンドリーファイアとローグエージェント：AIコーディングエージェントの新しいセキュリティ境界

はじめに

AIコーディングエージェントは、もはや単なる自動補完ツールではありません。リポジトリを読み込み、問題を調査し、ファイルを編集し、スクリプトを実行し、ツールを呼び出し、ネットワーク接続を開き、時には本番環境で使用可能な変更を作成します。これにより有用性が高まる一方で、セキュリティモデルも変化しています。

重要な問題は、もはやモデルが有害なプロンプトを拒否できるかどうかだけではありません。より難しい問題は、エージェントが実行時に何を許可されるかです。つまり、どのファイルを読み取れるか、どのスクリプトを実行できるか、インターネットにアクセスできるか、シークレットがマウントされているか、すべてのアクションが有用な監査証跡を残すかどうかです。

本記事では、フレンドリーファイアとローグエージェントに関する元の議論を、実際の開発ワークフローでAIコーディングエージェントを使用するチーム向けの実用的なセキュリティガイドとして再編成します。

核となる判断基準

フレンドリーファイアとローグエージェントに共通するシグナルはシンプルです。信頼できないコンテキストが、エージェントによって権威として扱われると危険になります。

リポジトリのREADME、依存関係のスクリプト、顧客がアップロードしたアーカイブ、チャットボットのコードブロックは、通常の入力に見えるかもしれません。しかし、エージェントがその入力を読み取り、ファイルシステム、シェル、ネットワーク、または認証情報へのアクセスを伴うアクションを実行する場合、その入力は事実上、信頼境界を越えたことになります。

本番環境での使用において、エージェントがツール呼び出しの許可について最終的な権限を持つべきではありません。エージェントはアクションを提案できますが、許可レイヤー、サンドボックス、ポリシーエンジン、人間のレビュアーが、そのアクションが実際に許可されるかどうかを判断すべきです。

フレンドリーファイアが重要な理由

フレンドリーファイアは、現実的なセキュリティワークフローに焦点を当てています。AIコーディングエージェントに、サードパーティまたはオープンソースのリポジトリの脆弱性をレビューするよう依頼することです。このワークフローは防御的に見えるため魅力的です。チームはエージェントに何かを攻撃するよう依頼しているのではなく、コードを検査し修正を提案するよう依頼しています。

問題は、セキュリティレビューには信頼できない素材を読む必要があることです。リポジトリには、単なるデータではないドキュメント、スクリプト、ビルドファイル、バイナリアーティファクト、コメントが含まれる可能性があります。また、エージェントを対象とした指示が含まれている場合もあります。

重要な教訓は、AIセキュリティツールについてパニックにならないことです。それは、証拠と権限を分離することです。

READMEには、プロジェクトが通常どのようにテストされるかが説明されているかもしれません。それが自動的にエージェントにそのテストを実行する権限を与えるべきではありません。依存関係スクリプトはリポジトリの一部かもしれませんが、自動的に信頼されるべきではありません。サードパーティのパッケージには、通常のセキュリティチェックのように見えるコマンドが含まれている場合があります。エージェントはそれを読み取ることができますが、実行にはより高いレベルの信頼が必要です。

リスクのあるパターンは次のようになります：

./security.sh

コマンド自体は無害に見えるかもしれませんが、重要なのはそれがどこから来たかです。ユーザーから明示的に要求されたものですか？モデルによって提案されたものですか？サードパーティのREADMEからコピーされたものですか？イシューコメントや依存関係スクリプトに埋め込まれていたものですか？これらのソースは同じレベルの信頼を持つべきではありません。

ローグエージェントから学ぶプラットフォームの教訓

ローグエージェントは、異なる種類のリスクを示しています。ローカルコーディングエージェントがリポジトリをレビューする代わりに、問題はクラウドAIにあります。

会話エージェントがマネージド実行環境内でコードブロックを実行できるプラットフォーム。

プロダクトチームとセキュリティチームにとって有用な教訓は、チャットボットは単なるプロンプトと応答ではないということだ。それらはランタイム環境、サービスアカウント、ネットワーク出口、セッション変数、ログ、共有インフラストラクチャ、デプロイ権限も含む可能性がある。

会話エージェントがコードを実行したり顧客データにアクセスしたりできる場合、それは本番アプリケーションと同様に管理されるべきである。つまり、最小権限、環境の分離、監査ログ、変更レビュー、明確な所有権が必要となる。それを単なる「会話設定」として扱うことは、実際のリスクに対してはあまりに弱すぎる。

共通する障害モード

フレンドリーファイアとローグエージェントは異なるインシデントだが、同じ障害モードを指し示している。すなわち、信頼されていないコンテキストに運用上の権限が与えられているということだ。

フレンドリーファイアのシナリオでは、信頼されていないリポジトリのコンテンツがエージェントに影響を与え、コマンドを実行させることがある。ローグエージェントのシナリオでは、エージェントプラットフォーム内でのコード実行が共有ランタイムの動作や機密性の高い会話データに影響を及ぼす可能性がある。MCP関連の研究でも同様の懸念が提起されている。ユーザー向けの承認ビューと、モデルが実際に受け取るメタデータが、必ずしも同じ信頼プロファイルを表しているとは限らないのだ。

だからこそ、セキュリティ設計は慎重なモデルだけに依存することはできない。モデルはリスクの推論には役立つが、信頼できない指示を読んだ直後に、自身のリスクの高いツール呼び出しを承認すべきではない。

より安全なアーキテクチャは、次の3つの層を分離する。

1. モデルの推論: エージェントがファイルを読み取り、アクションを提案し、リスクを説明する。
2. ポリシーの適用: 外部の層がどのアクションを許可するかを決定する。
3. ランタイムの封じ込め: 間違ったアクションが承認された場合でも、サンドボックスが被害を制限する。

推奨アーキテクチャ

1. ワークスペースを分離する

サードパーティのリポジトリ、未知の課題、依存関係の監査、顧客のアーカイブ、ダウンロードしたパッケージは、使い捨ての環境で開くべきである。コンテナまたは仮想マシンが適切なデフォルトとなる。

分離された環境では、ユーザーのホームディレクトリ、クラウド認証情報、パッケージレジストリトークン、SSH鍵、ブラウザプロファイル、本番設定をマウントしないようにする。ソースコードは読み取り専用で開始できる。書き込みアクセスは、エージェントが明確な計画を策定し、ユーザーがその範囲を承認した場合にのみ付与されるべきである。

適切なデフォルトは次のとおり。

• 個人のホームディレクトリのマウントなし
• 長期有効なクラウド認証情報なし
• デフォルトのパッケージマネージャートークンなし
• 制限のないアウトバウンドネットワークアクセスなし
• 一時的なパッケージキャッシュ
• 厳格な時間とリソースの制限
• 完全なコマンドログ記録

2. エージェントワークフローをフェーズに分割する

読み取り、編集、実行を1つの自動フローにまとめてはいけない。それらを分離する。

読み取りフェーズ: エージェントはファイルを検査し、リスクを特定し、計画を作成できる。

パッチフェーズ: エージェントは、理想的には信頼できないスクリプトを実行せずに、差分またはパッチを生成できる。

実行フェーズ: エージェントは、狭い許可リスト内でのみ承認されたコマンドを、タイムアウトとリソース制限付きで実行できる。

提案されたコマンドがREADME、課題コメント、依存関係スクリプト、または外部ドキュメントからのものである場合、承認UIはそのソースを表示すべきである。

明確に言えば、リポジトリが提案したコマンドと、ユーザーが明示的に要求したコマンドは同じではありません。

3. モデル判断の前に確定的スキャンを実行する

AIエージェントは説明やトリアージに有用ですが、可能な限り確定的ツールを先に実行すべきです。

例えば：

• コマンド実行前のシークレットスキャン
• インストールスクリプト前の依存関係脆弱性チェック
• リポジトリツール実行前のバイナリ検出
• モデル解釈前の静的解析
• パッケージ更新前のロックファイル差分レビュー
• 依存関係インストール前のスクリプトライフサイクル検査

エージェントは結果を要約し優先順位付けできますが、ベースラインスキャナを代替してはいけません。

サードパーティコードのワークフロー

信頼できないリポジトリの場合、最も安全なデフォルトは「検査してから実行しない」です。

1. リポジトリをクリーンな使い捨て環境にクローンする。
2. 認証情報ヘルパーを無効にし、ホストのシークレットをマウントしない。
3. 一時的なパッケージキャッシュを使用する。
4. 親ディレクトリへのアクセスを制限する。
5. エージェントにファイルを読み取らせ、リスク計画を作成させる。
6. 依存関係をインストールする前にライフサイクルスクリプトを確認する。
7. エージェントに実行したい各コマンドの出所と目的を説明させる。
8. 時間、ネットワーク、ファイルシステムの制限付きで承認済みコマンドのみ実行する。
9. レビュー済みの成果物（パッチ、レポート、再現メモなど）だけを持ち帰る。
10. パッケージキャッシュ、生成バイナリ、シェル履歴、ランタイム状態をサンドボックスから持ち帰らない。

シンプルで有用なルール：入力の信頼度が低いほど、エージェントに与える権限も小さくすべきです。

プロダクトチームがAIエージェントの権限を設計する方法

単一の「セーフモード」切り替えだけでは不十分です。実際の製品には機能レベルの権限が必要です。

より優れた権限モデルは、各機能を個別に扱います：

機能	推奨デフォルト	重要性
ファイル読み取り	スコープ付きワークスペースで許可	エージェントにはコンテキストが必要だが、マシン全体は不要。
パッチ書き込み	計画レビュー後に許可	コードの書き込みは実行よりも安全。
テスト実行	許可リストのみ	テストコマンドは任意のスクリプトを呼び出せる。
依存関係インストール	承認必須	パッケージのライフサイクルスクリプトは大きなリスク面。
ネットワークアクセス	信頼できない作業ではデフォルト拒否	情報漏洩やリモートペイロード取得を防止。
シークレットへのアクセス	デフォルト拒否	シークレットは信頼できないタスクから見えてはいけない。
Pull Request作成	承認必須	PRは信頼できるリポジトリやCIシステムに影響を与える可能性がある。
デプロイ	手動承認必須	デプロイは本番環境に影響を与えるアクション。

承認画面では、コマンドだけでなく、その出所も表示すべきです。ユーザーの意図、モデル推論、READMEの指示、CI設定、外部Issueコメントからのコマンドは、異なるラベルで表示されるべきです。

NxCodeワークフローへの影響

NxCodeユーザーは、エージェントに実際の開発作業（コード読み取り、ファイル更新、チェック実行、デプロイ成果物生成、ドキュメント作成）を処理させたいとよく望みます。これらの機能は価値がありますが、権限境界が明確である場合に限ります。

実践的なアプローチとして、タスクを3つのグループに分類します：

1. 信頼できる環境における低リスク作業

リポジトリ
例としては、フォーマット修正、ドキュメントの更新、小さなUI変更、テストの提案などが挙げられます。これらは、リポジトリと環境が信頼できる場合には、より高い自動化を適用できます。
2. 信頼できない入力に関する調査
例としては、未知のリポジトリ、依存関係の更新、外部からの issue 報告、顧客がアップロードしたアーカイブなどが挙げられます。これらは、使い捨ての制限された環境で実行すべきです。
3. 本番環境に影響を与える操作
例としては、デプロイ、データベースのマイグレーション、シークレットのローテーション、インフラストラクチャの変更、CI/CD の権限更新などが挙げられます。これらには人間による承認と強固な証拠ログが必要です。

この設計は、AI コーディングエージェントのスピード面での利点を損なうものではありません。リスクが低い箇所ではエージェントの高速性を維持し、影響範囲が大きい箇所ではより構造化されたプロセスを強制します。

ソースに関する注記

• 原文言語: 中国語。
• 出力言語: 英語。
• 画像処理: ソースページには汎用的なブログカード画像と NxCode ロゴが表示されていますが、記事本文に強く必要な固有の本文スクリーンショット、ワークフロー図、結果画像はありません。これらの汎用的・ナビゲーション用画像は Markdown 本文には挿入されていません。
• 広告・ナビゲーション処理: プロダクトナビゲーション、フッターリンク、プロモーション用 CTA ブロック、関連性のないサイトモジュールは除外しました。
• 著作権注記: 最終記事は原文ページの逐語的なコピーではなく、英語で書き直し、再構成した公開用のバージョンです。

FAQ

AI コーディングエージェントのセキュリティにおけるフレンドリーファイアとは何ですか？

フレンドリーファイアとは、防御的な作業に使用される AI エージェントが、信頼できないコードベースの内容に影響を受けるリスクパターンを指します。エージェントがサードパーティのリポジトリを読み込み、ドキュメントやスクリプト内の指示を安全な操作ガイダンスとして誤って解釈する可能性があります。

ローグエージェントとは何ですか？

ローグエージェントは、Dialogflow CX におけるセキュリティ問題として報告されており、エージェントのワークフロー内でのコード実行に関連します。その広範な教訓は、コード実行機能、セッションアクセス、クラウドランタイム権限を持つ AI チャットボットは、単なる会話スクリプトではなく、プロダクションソフトウェアとして扱わなければならないということです。

なぜ AI コーディングエージェントはプロンプトインジェクションに対して脆弱なのですか？

AI コーディングエージェントは、しばしば信頼できないファイルを読み込み、その学習内容に基づいてツールを使用します。リポジトリ、issue、ドキュメントに隠された指示が含まれている場合、エージェントは信頼できないコンテンツと信頼されたユーザーの意図を混同する可能性があります。

サンドボックス化だけで AI コーディングエージェントを保護するのに十分ですか？

サンドボックス化は重要ですが、唯一の防御策であってはなりません。安全な設定には、権限の境界、ネットワーク制限、シークレットの分離、決定的なスキャン、コマンドの来歴、監査ログも必要です。

AI エージェントは README ファイルからコマンドを自動実行すべきですか？

自動的には実行すべきではありません。README のコマンドは有用なドキュメントになり得ますが、それらは調査対象のリポジトリに由来します。信頼できないプロジェクトの場合、エージェントはコマンドのソースとリスクを説明し、その後に実行の承認を得るべきです。

チームは AI エージェントを用いてサードパーティのリポジトリをどのように扱うべきですか？

使い捨ての環境を使用し、シークレットのマウントを避け、ネットワークアクセスを制限し、まず静的チェックを実行し、レビュー済みのパッチやレポートのみを持ち帰ります。サンドボックスの状態や生成されたアーティファクトをデフォルトで信頼してはいけません。何を

AIコーディング製品が公開すべき権限とは

製品は、ファイルの読み取り、パッチの書き込み、テストの実行、依存関係のインストール、ネットワークの利用、シークレットへのアクセス、プルリクエストの作成、デプロイといった各機能に対して、きめ細かな制御を提供すべきです。それぞれの機能には、独自のスコープ、予算、ログ、承認ルールが必要です。

関連ツール

• Claude Code: Anthropicのエージェント型コーディングツール。コードベースの読み取り、編集、操作に対応。
• OpenAI Codex: サンドボックスと承認の概念を備えたOpenAIのコーディングエージェントプラットフォーム。
• Google Dialogflow CX: プレイブックやコードブロック機能を含むGoogle Cloudの会話型エージェントプラットフォーム。
• Docker: 使い捨ての開発・テスト環境を作成する一般的な方法。
• Semgrep: エージェントによる実行前にソースコードをスキャンできる静的解析ツール。
• GitHub CodeQL: セキュリティレビューワークフローに有用な意味論的コード解析エンジン。

関連リンク

• AI Now Friendly Fire 調査: 防御的なAIエージェントとリモートコード実行リスクに関する調査概要。
• Varonis Rogue Agent 開示: Dialogflow CX Rogue Agent脆弱性に関する技術解説。
• Claude Code セキュリティドキュメント: Claude Codeに関するAnthropic公式のセキュリティガイダンス。
• Claude Code オートモード: Claude Codeにおけるオートモードと権限決定に関するAnthropicの解説。
• OpenAI Codex サンドボックスドキュメント: Codexがサンドボックス境界をどのように使用するかに関する公式説明。
• OpenAI Codex 自動レビュー: Codex自動レビューの動作に関する公式ドキュメント。
• Dialogflow CX コードブロック: Dialogflow CXプレイブックにおけるPythonコードブロックに関するGoogle Cloudドキュメント。

まとめ

Friendly FireとRogue Agentが示すように、AIエージェントのセキュリティは単なるモデルアライメントの問題ではありません。実質的な境界はランタイム、すなわちファイル、コマンド、ネットワークアクセス、シークレット、実行環境、そして監査可能性にあります。

AIコーディングエージェントを利用するチームは、タスクが防御的なものであっても、信頼できないリポジトリや外部コンテキストを信頼できない入力として扱うべきです。エージェントは調査や説明を支援できますが、実行はサンドボックス、ポリシー、スキャナ、明示的な承認によって制御されるべきです。

最も安全なパターンはシンプルです。エージェントには幅広く推論させつつ、運用権限は狭く付与することです。