7月31日、NVIDIAが「Four Ways to Deploy More Secure AI Agents」と題した記事を公開した。NVIDIAのAI Red Teamが過去6か月にわたって複数のAIエージェントを評価した結果、フレームワークや構成を問わず同じ失敗パターンが繰り返し現れたという。本記事はその知見をもとに、本番展開で踏むべき4つの対策を具体的にまとめたものだ。
AIエージェントを「デジタルな同僚」として業務に組み込む動きが加速している。バグレポートの確認からパッチ適用・レビュー依頼まで一連の作業を自律的にこなすエージェントは、生産性向上の手段として注目を集めている。一方で、LLMに企業データや外部ツールへのアクセス権を与えることは、攻撃対象領域が不明確な特権ソフトウェアを生み出すリスクと表裏一体だ。評価対象はシンプルなコーディングツールから常時稼働の自律エージェントまで多岐にわたり、そのいずれにも共通の弱点が確認された。
最も深刻な落とし穴：コード実行の制御不備
4つの対策の中で、エンジニアが最も注目すべきはコード実行の制限だ。
多くのエージェントはBashシェルやコマンド実行ツールを汎用的に使える状態で公開されている。攻撃者がモデルへの入力に介入できれば（直接入力だけでなく、プロンプトインジェクション経由でも）、任意のコマンドを実行させることが可能になる。
よく見られる対策として「LLM-as-a-judge」パターン（別のLLMが出力を審査して有害なコマンドをブロックする手法）や許可コマンドのallowlist化がある。しかしNVIDIAの評価では、これらはいずれも不十分だった。
理由は単純で、コーディングエージェントはpytestやnpm installを日常的に実行する。そのためLLM-as-a-judgeはこれらのコマンドを受け入れる傾向があり、攻撃者がコントロールした入力経由で実行される場合も同様に通過してしまう。
さらに深刻なのが、コマンド実行ツールが存在しない場合でもファイル書き込みが抜け穴になる点だ。~/.bashrc、~/.gitconfig、hooks.json、MCP.jsonといったファイルにエージェントが書き込めた場合、別プロセスがそのファイルを実行した時点でコード実行が成立する。記事では「コマンド実行が直接できない状況でも同様のリスクがある」と明記されている。
悪用の具体例も報告されている。以前のブログ記事では、Pythonスクリプトの作成・実行を依頼するだけでリバースシェル（RCE）を取得できたケースが紹介されている。
推奨対策：
- コマンドラインツールは可能な限り排除する
- 書き込みはOSレベルで非実行可能なワークスペース外をブロックする
- コマンド実行が必要な場合は、DockerやVM、NVIDIAのOpenShell（※編集部注：元記事に記載のツール名。公式リポジトリは元記事内リンクを参照のこと）など隔離された環境で実行し、厳格なallowlistを設ける
残る3つの対策
アクセス制御の実装
評価対象エージェントの中には、個人ユーザーの認証情報を保持しながら社内ネットワーク上の任意ユーザーがアクセスできる状態のものが複数あった。エージェントは明示的に認可されたユーザーのみに限定し、そのユーザーの権限に合わせた最小権限で動作させることが基本となる。
ネットワーク外部通信のデフォルト拒否
アウトバウンド接続を放置すると、データ外部送信やリバースシェル・SOCKSプロキシによる直接侵入が可能になる。エージェントのタスクに必要な最小限のエンドポイントのみを許可するallowlistを設け、エージェント自身がアクセスできない環境レベルでネットワーク制御を実施する必要がある。
シークレットをエージェントの手の届かない場所に置く
APIキーやOAuthリフレッシュトークンなどの認証情報を環境変数としてコンテナにインジェクトする方法は、任意コードを実行しないアプリケーションでは標準的だが、エージェント環境では危険だ。エージェントがenvやprintenvを実行するだけで認証情報が丸見えになる。評価では、リバースシェルが取得できない状況でも「Frog-boiling攻撃」（Crescendo攻撃とも呼ばれる段階的な誘導手法）を使い、チャットインターフェース経由でシークレットを引き出すことができた。
推奨は、専用のシークレットマネージャーに認証情報を格納し、必要なプロセスのメモリ内でオンデマンドに取得する方法だ。可能であれば、短命で最小権限のエフェメラルトークンを発行するトークンブローカーを使う。
プロンプトベースの防御は機能しない
記事全体を通して繰り返し強調されているのが、LLM自体のコントロール平面上にある防御は確実に突破されるという点だ。
Red Teamは以下の3つの汎用手法で、評価対象のほぼすべてのシステムを突破している：
- 文脈の偽装：「デバッグ中」「管理者ユーザー」と称することで、エージェントがリバースシェルを書いて実行するケースもあった
- Frog-boiling（段階的誘導）：複数のやり取りを通じて徐々に望ましい動作に誘導し、過去の会話履歴を「信頼の根拠」として利用する
- 正規ワークフローを使ったミスディレクション：悪意のあるパッケージを作成し、
pip install git+https://…でインストールさせることで、インストール処理中に任意コードを実行させる（Black Hat 2025での発表で初報告）
フロンティアモデルは敵対的操作に対してより頑健だが、「十分な時間と専門知識があれば、ほぼすべてのモデルは依然として突破できる」とNVIDIAは結論づけている。
推奨コントロールの優先順位
記事では以下を重要度順にまとめている。この順番には意図がある。アクセス制御とコード実行の隔離が先頭に置かれているのは、これらが未対処の場合、後続のシークレット管理やネットワーク制御が機能しても攻撃者に足がかりを与えてしまうためだ。逆に言えば、リソースが限られるチームはまずこの2点から着手することが合理的な判断となる。
- エージェントへのアクセス制御（認証済み特定ユーザーのみ）― 攻撃対象を絞る第一関門
- 任意コード実行はサンドボックス内のみ（Docker、OpenShell、VM）― 侵害が起きても被害を封じ込める
- ネットワーク外部通信のデフォルト拒否― データ漏洩とリバースシェルの出口を塞ぐ
- シークレットを環境に露出させない― 認証情報を奪われてもラテラルムーブメントを防ぐ
- パッケージインストールは検証済みリポジトリのみ許可― サプライチェーン経由の侵入を遮断する
- ツール・MCP・スキルの最小権限化― エージェントの行動範囲そのものを狭める
- 永続ストレージの最小権限化（書き込み可能なパスが後で実行されないよう管理）
- 最新のフロンティアモデルの使用（特にLLM-as-a-judgeパターンで有効）― より堅牢なモデルほど誘導が難しい
詳細はFour Ways to Deploy More Secure AI Agentsを参照していただきたい。
