直接回答： コード支援ツールが、リポジトリを読み、コマンドを実行し、ツールを呼び出すエージェントになると、その最大のリスクは「誤ったコード」を生み出すことから「危険な操作」を実行することへと移ります。OWASP Top 10 for LLM Applications（2025）は、プロンプトインジェクション、機微情報の漏えい、サプライチェーンの弱点、不適切な出力処理、過剰なエージェンシーを主要なリスクに挙げています。本チェックリストは、これらのカテゴリを具体的な統制へと対応づけます——とりわけ、セルフホストのエージェントを運用するチームに向けて。
コード補完ツールが誤った1行を提案するのは、生産性の問題です。しかし、攻撃者の影響を受けたIssueを読み込み、あなたの認証情報でシェルコマンドを実行するコーディングエージェントは、セキュリティの問題です。両者の違いは自律性とツールの組み合わせにあり、それが脅威モデルを根本から変えます。
2025年に更新された OWASP Top 10 for LLM Applications は、このモデルについて最も広く参照される出発点です。以下では、その各カテゴリを、AIコーディングエージェントに現れる具体的な形と、それらに対処する統制へと読み替えます。
コーディングエージェントが脅威モデルを変える理由
現代のコーディングエージェントは、通常次のように振る舞います：
- 信頼できないコンテンツを取り込む——Issueの本文、コードコメント、Webページ、依存関係のREADME
- ツールと権限を持つ——シェル、Gitアクセス、ネットワークの外向き通信、パッケージのインストール
- 一定の自律性をもって動く——人間が各ステップを承認しなくても、複数の操作を連鎖できる。
この組み合わせは、エージェントが読むコンテンツに潜む悪意ある指示が、悪意ある「操作」になりうることを意味します。モデルの出力を守るだけでは不十分で、エージェントに何が「できる」かを制約しなければなりません。
2025年版OWASP LLM Top 10をコーディングエージェントに適用する
| OWASPカテゴリ（2025） | コーディングエージェントでの現れ方 | 主要な統制 |
|---|---|---|
| Prompt Injection (LLM01) | Issue、コメント、依存関係に潜む指示がエージェントの動きを変える | ツールを制約し、影響の大きい操作には人間の承認を要求する |
| Sensitive Information Disclosure (LLM02) | ソース、シークレット、プロンプトがモデル提供者やログに送られる | 外向き通信の制御、シークレットのマスキング、範囲を絞った認証情報 |
| Supply Chain (LLM03) | 汚染されたモデル、パッケージ、プラグインがワークフローに入り込む | 出所を固定・検証し、内部ミラーを使う |
| Improper Output Handling (LLM05) | 生成されたコードやコマンドが検査なしで実行される | サンドボックス実行と必須のレビュー関門 |
| Excessive Agency (LLM06) | エージェントが、タスクに必要な以上の権限や自律性を持つ | 最小権限と、明確に境界づけたタスク範囲 |
| System Prompt Leakage (LLM07) | プロンプトに埋め込まれた構成やシークレットが露出する | シークレットをプロンプトから外し、プロンプトは漏れうると想定する |
OWASPはこのリストと採番を定期的に改訂します。これらに対して統制マトリクスを構築する前に、OWASP Gen AI Security Project で現在の項目と定義を確認してください。
チームのための統制チェックリスト
ツールを問わず、実際のリポジトリへのアクセスをエージェントに与える前に、次の項目を順に確認してください：
- 信頼境界。 信頼できない入力がどこから入り、エージェントがどこで行動できるかを図にします。エージェントが読むあらゆるコンテンツに指示が含まれうると想定してください。
- 最小権限。 タスクに必要な最も狭い認証情報、リポジトリ、ネットワーク範囲だけを与えます——常設の権限は残しません。
- 外向き通信の制御。 モデルのエンドポイント、Gitホスト、パッケージレジストリ、テレメトリ、ログといった、あらゆる外向きの経路を把握し、制限します。
- シークレットの衛生。 認証情報をプロンプトや生成物に含めないようにし、エージェントが観測しえたものはすべてローテーションします。
- サンドボックスと隔離。 使い捨てで、リソースが制限され、既定では本番に到達できない環境で実行します。
- 人間によるレビュー関門。 影響の大きい操作——マージ、デプロイ、インフラ変更、依存関係の追加——の前にレビューを要求します。
- ロギングと監査。 タスク、ツール呼び出し、結果を記録し、意外な操作を調査できるようにします。
- サプライチェーンの検証。 モデルとパッケージの出所を固定し、完全性を検証し、エアギャップや規制対象の業務では内部ミラーを優先します。
- モデルとデータの条項。 提供者が何を保持し、何で学習し、どこでデータを処理するかを確認します。
- インシデントのリハーサル。 まず非機密のコードでテストし、アクセスの取り消しとエージェント操作のロールバックを演習します。
セルフホストが役立つところ——そして役立たないところ
エージェント基盤をセルフホストすると、組織は外向き通信、隔離、ロギング、データレジデンシーを実際に制御できます。これらはまさに複数のOWASPカテゴリが依存するレバーであり、だからこそセルフホスト型のデプロイは、規制対象や専有の業務にとって魅力的です。
しかし、セルフホストそれ自体は、プロンプトインジェクションや過剰なエージェンシーを取り除きません。これらのリスクは、エージェントがコンテンツをどう処理し、どのツールを呼び出せるかに宿るのであって、サーバーがどこで動くかにあるのではありません。広範な認証情報を持ち、レビュー関門のないセルフホストのエージェントは、依然として危険です。
MonkeyCodeの公開資料は、プライベートかつオフラインのデプロイと、タスクとレビューを中心とした管理型のワークフローを説明しています。それらは、これらの統制を支える有用な基盤として扱い、統制の代替とはしないでください。次に読む価値のある関連の直接回答が2つあります：セルフホストは自動的にプライベートになるのか、そしてMonkeyCodeはコードを外部に送信するのか。あわせて、本サイトのセキュリティとデータフローの境界もご覧ください。
結論
アシスタントからエージェントへの移行は、「コードは正しいか？」から「このシステムは何ができ、誰が承認したのか？」への移行です。2025年版OWASP LLM Top 10でリスクを洗い出し、最小権限とレビュー関門で操作を制約し、境界を信頼する前に非機密のコードで各統制を検証してください。セルフホストはこれらの統制のいくつかを強化できますが、それらを置き換えるものではありません。
出典の範囲： ここで参照したリスクカテゴリは、OWASP Top 10 for LLM Applications（2025年版）に基づき、2026年7月20日に確認しました。OWASPは時とともにリストを改訂します。現在の項目と採番は直接ご確認ください。本記事は一般的なセキュリティの指針であり、特定の製品やデプロイを推奨・保証するものではありません。