AIエージェントをより安全にデプロイする4つの方法

ナレッジワーカーは業務ワークフローにAIエージェントをますます統合しています。「デジタル同僚」として機能するエージェントは明確な利点を提供します。例えば、バグレポートをレビューし、修正を実装・テストし、パッチをプッシュし、レビューを求めるために人間にpingを送信することができます。定型業務を処理することで、エージェントは大きな生産性向上をもたらす可能性があります。一方で、LLMをエージェントハーネスを通じてライブツールや企業データに接続することは、役立つアシスタントを、攻撃対象領域が十分に理解されていない特権ソフトウェアに変えてしまうリスクを伴います。

過去6ヶ月間、NVIDIA AI Red Teamは、シンプルな対話型コーディングツールから常時稼働の自律型デジタルアシスタントまで、複数のAIエージェントを評価しました。エージェントが悪用可能であることが判明した場合、フレームワークやハーネスに関わらず、同じ主要な障害モードを通常観察しました。これには以下が含まれます：

• エージェントへのアクセス制御の欠如
• 任意のコード実行を可能にするエージェントツール
• ネットワーク出口制御の不在
• 平文でエージェントに公開されるシークレット

本記事では、これらの障害モードを検証し、敵対的な圧力に耐える制御策について説明します。例はチャット接続型エージェント（評価で最も多く遭遇したタイプ）に焦点を当てていますが、パターンはあらゆるエージェントに一般化できます。

エージェントアクセス制御の実装

現在のAIデプロイメントにおける最も一般的な障害モードは、エージェントへのアクセス制御の欠如です。個別ユーザーの認証情報を保持し、内部ネットワーク内の認証済みユーザーなら誰でもアクセス可能な複数のエージェントを発見しました。これはエージェントの正当な認証情報の誤用を招くだけでなく、後述の例のように、認証情報を収集してエージェントの本来の文脈外で使用することも可能にしました。

推奨事項：

• 敵対的活動に対する第一の防御線として、強力なアクセス制御を使用する。
• 各エージェントを明示的に認可されたユーザーのみに制限する。認可されていないユーザーに応答しないエージェントは、テストが著しく困難であった。
• 最小権限の原則に従い、エージェントの権限をそれを呼び出すユーザーの権限に合わせる。

コード実行の制限

多くのハーネスはBashシェルまたはコマンド実行ツールを公開しています。これらは汎用性が高いため使用されます。機能ごとに別個のツールを必要とせずに、幅広い定型業務をサポートします。しかし、モデル出力がコマンド実行を制御する場合、直接的な入力や間接的なプロンプトインジェクションを通じてその出力を影響できる攻撃者は、実行環境でコマンドを実行できる可能性があります。これにより、データ漏洩やホスト上での実行持続などの悪意ある結果を達成できる可能性があります。

この任意のコマンド実行リスクに対する一般的な緩和策は、有害または悪意のあるコマンドの実行をブロックするためのLLM-as-a-judgeレビューエージェントの使用、許容コマンドの許可リストの使用、または単にモデルが「より良く知っている」と信頼することです。いずれも敵対的操作に対する防御は限定的です。

多くの一般的なエージェントコマンドラインタスクは、一般的な開発ワークフローとテスト駆動開発をサポートします。つまり、pytestやnpm installなどのコマンドの実行を一般的に必要とするため、LLM-as-a-judgeパターンはこれらのコマンドの実行を受け入れやすい傾向があります。しかし、攻撃者制御の入力によって影響を受けると、これらのコマンドは任意のコマンド実行と同等になります。

場合によっては、リバースシェルによる完全なリモートコード実行（RCE）の取得は、エージェントにPythonスクリプトの作成と実行、またはリモートパッケージのインストールを求めるだけで済み、本トピックに関する以前のブログ記事で示した通りです。

コマンドラインツールがなくても、エージェントが実行されている環境とファイルの読み書きツールを通じてやり取りする能力も、しばしばコード実行や権限昇格への予期しない経路を公開します。

攻撃者が~/.bashrcや~/.zshrcなどのシステムファイル、または~/.gitconfig、hooks.json、MCP.json、スキルファイルなどの設定ファイルにコンテンツを書き込むことができれば、別のプロセスが関連ファイルを実行する際にコード実行を達成できます。コマンドライン実行が直接利用できない場合でもです。エージェントが書き込める場所とファイルは厳密に制御され、実行不可能な場所に制限されるべきです。

推奨事項：

• アクセス可能なエージェントにおける単一の最高影響リスクとして、任意のコード実行を扱う。
• 可能な限りコマンドラインツールを避ける。
• OSレベルで実行不可能なワークスペース外への書き込みをブロックする。
• コマンドライン実行ツールが必要な場合、厳密な最小権限の実行可能コマンドの許可リストを使用し、次に詳述するように、強力なネットワーク出口制御を備えた分離実行環境でツールを実行する。
• コマンドライン経由でファイル名、文書タイトル、その他の外部データなどの引数や文字列を処理する際は注意する。パストラバーサルやコマンドインジェクションを防ぐため、使用前にサニタイズと正規化を確実に行う。

デフォルトでネットワーク出口を拒否

アウトバウンドネットワーク接続は、データ漏洩や、リバースシェルやSOCKSなどの直接接続の作成を許可し、攻撃者がエージェントのランタイム環境と直接やり取りできるようにします。ネットワーク出口制御が強制され、適切に最小権限が適用されている場合、すべてのやり取りをエージェントプロセス経由で行う必要があり、実行速度が低下し、影響の信頼性が低下しました。エージェントの状態とアライメントの維持、出力フィルターのナビゲート、エージェントが要求を拒否し始めた後のセッションの再起動と操作はすべて運用負担を増加させました。

推奨事項：

• エージェントが実行することが期待されるタスクに必要な最小限のエンドポイントの最小権限許可リストを備えた、デフォルト拒否のネットワーク出口ポリシーを適用する。
• エージェントがアクセスするすべてのネットワーク境界で、エージェントがアクセスできない環境制御を使用してこれらの制限を強制する。

シークレットをエージェントの到達範囲外に保つ

エージェントは意図した機能を実行するためにシークレットへのアクセスを必要とすることがよくあります：プラットフォームトークン、APIキー、バージョン管理システム（VCS）アクセストークン、場合によってはOAuthリフレッシュトークンです。従来のセキュリティアドバイスでは、ディスクへの書き込みを防ぐためにメモリ内の環境変数としてシークレットを注入することを推奨していますが、これはコードのみがコンテナで実行される場合に合理的です。

コマンド実行を持つエージェントがその環境を共有する場合、env、printenv、または/proc/self/environの実行を誘導することで、それらを直接検査できます。コマンドラインツールは特に高リスクであることを強調する価値があります。CLIは認証情報を予測可能な場所にディスクにキャッシュし、容易に表示します。gitリポジトリ、.envファイル、bash履歴、.netrcファイル、OAuth 2.0リフレッシュトークン、実行環境の環境変数にトークンを観察しました。

リバースシェルを確立できなかった場合でも、チャットインターフェースを通じて認証情報を漏洩できることがよくありました。「カエルを茹でる」アプローチ（以下参照）を使用して、エージェントを独自の実行環境内に公開されたいくつかのシークレットを表面化させるように導きました。出口制御はネットワーク経由の直接的な漏洩やファイルシステムでの直接的な検査を防ぎましたが、認証情報は環境内に公開されたままであり、LLMが到達可能であり、チャットインターフェースを介して私たちに提供されました。

推奨事項：

• 永続的なシークレットをエージェントがアクセス可能にしない。
• 専用のシークレットマネージャーにシークレットを保存する。
• 必要とするプロセスのメモリ内でのみ、オンデマンドでシークレットを取得する。
• シークレットをエージェントのコンテキストウィンドウと実行環境から遠ざける。
• タスクに認証情報が必要な場合、短期間で範囲の狭いトークンを使用し、タスク完了後すぐにトークンを失効させる。

第一の防御線として決定論的制御を使用する

最も頻繁に遭遇する緩和策は、リスクの高いまたは危険な行動を避けるようモデルに指示するシステムプロンプトであり、時には入出力の判断を行う2番目のモデル（LLM-as-a-judgeパターン）によって強化されます。これらはすべてLLMによって強制され、LLM自体と同じ確率論的で信頼性の低い動作を継承します。

これらの種類の制御を確実に打ち負かす3つの一般的な手法があります。それぞれを複数のシステムで示します。

悪意のある活動が正当に見える文脈をエージェントに提示するだけで、驚くほど効果的でした。エージェントに対して「デバッグ中」または「管理者ユーザー」であることを示唆することが多く、その後、要求に定期的に従いました。あるエージェントは、私たちのためにリバースシェルを記述して実行するところまで行きました：

他のケースでは、ファイル編集ツールの使用をエージェントに指示することで、エージェントメモリとAGENT.mdファイルを直接操作することが可能であり、「デバッグ」および「認可ユーザー」フレームの構築も可能になりました。

カエルを茹でる

「カエルを茹でる」（Crescendo攻撃と呼ばれることもある）は、複数のやり取りを通じて徐々にエージェントを望ましい行動に誘導し、以前の会話履歴を使用して信頼性と要求の無害性を確立します。シークレット抽出は、正当に見えるワークフローを実行しようとすることでエラーを誘発し、最終的に「エラーの根本原因はシークレットに関連している」と「発見」し、エージェントを説得してそれらを明らかにさせることで進行しました。

正当なワークフローによる誤誘導

パッケージインストールなどの誤誘導攻撃（Black Hat 2025のFrom Prompts to Pwnsで最初に説明）は、依然として非常に効果的です。明らかに無害な行動を取るようにエージェントを誘導し、それが副作用としてコード実行を引き起こすことで、通常、エージェントの抵抗を回避するのは簡単です。

コーディングエージェントは定期的にライブラリをインストールします。この記事で説明されているように悪意のあるライブラリを作成し、pip install git+https://…経由でインストールするようエージェントに依頼することは、標準的な要求のように見えます。しかし、武器化されたパッケージはインストールプロセス中に任意のコード実行を作成します。

推奨制御策

一貫した発見は、LLMと同じ制御プレーンにある防御、特にプロンプトベースの防御が定期的に破られるということです。制御はモデルの制御プレーンの外で強制されなければなりません。

重要度の概ね高い順に推奨される制御策は以下の通りです：

• エージェントにアクセス制御を使用する。特定の認証済みユーザーのみがエージェントとやり取りできるようにする。
• 任意のコマンド実行はサンドボックス環境でのみ実行する：Docker、NVIDIA OpenShell、または仮想マシンなど。環境はエスケープに対して適切に強化されていなければならない。環境は、環境やエージェント設定ファイルの書き込みや編集によって自身を設定できるものであってはならない。
• デフォルト拒否のネットワーク出口：タスクに必要な特定のネットワークリソースの最小権限許可リストを、エージェントがアクセスするすべての境界で。
• シークレットを静止状態や環境に公開しない。非エージェントアプリケーションでは環境変数としてシークレットを注入するのが標準ですが、これは任意のコードを実行するワークロードでは安全ではありません。シークレットはシークレットマネージャーに保存し、オンデマンドでアクセスし、必要とするプロセスに限定するべきです。可能な場合は、最小権限の一時トークンを提供するトークンブローカーを使用するべきです。
• 検証済みパッケージリポジトリからのパッケージインストールのみを許可する。デフォルトで任意のURLおよびVCSベースのインストールをブロックする。
• 最小権限のツール、MCP、スキルなど。ジョブに必要なツールのみ。実行、書き込み、またはネットワークに到達するものはすべて精査する。
• 最小権限の永続ストレージ。ボリュームマウントを避ける。避けられない場合は、厳密に範囲を限定し、後で実行されるパスに書き込み可能なものをマウントしない。
• 最新/最先端のモデルを使用する、特にLLM-as-a-judgeパターンでは、敵対的操作に対してより堅牢である可能性がある。

結論

AI Red TeamのAIエージェントのセキュリティ確保における経験は、AIエージェントの防御における決定論的な「ハード」制御の継続的な必要性を強調しています。企業認証情報を持つ完全に自律的なシステムは本質的にリスクが高く、慎重に保護されなければなりません。最先端モデルは敵対的操作をより困難にしますが、十分な時間と専門知識があれば、そのほとんどすべてが依然として破られる可能性があります。

観察された一般的な欠陥には、弱いアクセス制御（誰でもエージェントにアクセス可能にする）、RCEの機会を生む実行およびファイル書き込みツール、データ漏洩とリバースシェルを許可する不十分なネットワーク出口制御、エージェントがアクセス可能な実行環境内の平文のシークレットが含まれます。

LLM-as-a-judgeパターンを含むプロンプトベースのガードレールは、これらのギャップを埋めません。アーキテクチャ制御が埋めます：エージェントへのアクセス制御、企業データへの最小権限アクセスを備えた強化されたサンドボックス、デフォルト拒否のネットワーク出口制御、エージェントの到達範囲外に保たれたシークレットです。適切に設定され強制されれば、これらの制御はAIエージェントの敵対的悪用の削減に非常に効果的です。

第一原則から安全なエージェントを設計する方法の詳細については、「企業AIファクトリにおける自律エージェントのガバナンス方法」テクニカルブログを参照してください。これは、Secure Agent Workspace Reference Designの実装の最初のステップをガイドします。

エージェントセキュリティの詳細については、Black Hat USAでのNVIDIAプレゼンテーションをお見逃しなく：Cost-Effective, Private, Frontier-Grade: AI Agent Exploitation with a Fine-Tuned OSS Model

NVIDIA AI Red Teamのその他の記事については、こちらをご覧ください。