AIエージェントに「安全なコマンド」を許可しただけで任意コード実行、Dockerが解説するコマンド承認の落とし穴

AIを使ってプログラミングを支援する「AIコーディングエージェント」では、危険なコマンドを実行する前にユーザーへ確認を求める仕組みが使われています。しかしDockerは2026年8月18日に、安全に見えるコマンドをユーザーが承認しても攻撃者のコードが実行される可能性がある事例を紹介しました。

Coding Agent Horror Stories: The Command You Already Approved | Docker
https://www.docker.com/blog/coding-agent-horror-stories-the-command-you-already-approved/

AIコーディングエージェントはコードの作成だけでなく、ターミナルでコマンドを実行することもできます。毎回許可を求めると作業が中断されてしまうため、「git」など安全性が高いと判断したコマンドを許可リストに登録して自動実行する仕組みも用意されています。

Dockerが取り上げたのはAIコードエディタ「Cursor」で見つかった脆弱(ぜいじゃく)性「CVE-2026-22708」です。Cursor 2.3で修正済みの脆弱性ですが、問題となった環境では「export」など一部のシェル組み込みコマンドがユーザーへの確認なしで実行でき、環境変数を書き換えることが可能でした。

例えばGitは出力の表示方法を決める際に「PAGER」という環境変数を参照します。攻撃者がAIエージェントを誘導してPAGERを書き換えた後、ユーザーが安全に見える「git branch」を承認すると、Gitの処理をきっかけに攻撃者が指定したコードを実行できます。

環境変数を悪用する手法自体は以前から知られていました。しかしAIエージェントはREADMEや依存パッケージ、Issueのコメントなどに含まれる文章を読み取り、複数の操作を自動で続けて実行できます。そのため従来は端末へのアクセスと複数の操作が必要だった攻撃を、悪意のある文章を読み取ったAIエージェントが自動的に進める可能性が生まれています。Dockerはコマンド名だけを確認する許可リストでは、AIエージェントの安全性を十分に確保できないと説明しています。

対策としてDockerが紹介しているのが「Docker Sandboxes」です。Docker SandboxesはAIコーディングエージェントをホストOSとは分離された小型の仮想マシン「microVM」内で動かす仕組み。AIエージェントが自由にコードを実行できる環境を用意しつつ、認証情報や外部ネットワークへのアクセスをサンドボックスの外側で制御します。

Docker SandboxesではAIエージェントをmicroVM内に配置し、外部との通信はプロキシを経由させます。APIキーなどの生の認証情報やSSH秘密鍵のファイルをmicroVM内へ直接置かず、アクセス可能なネットワークもルールによって制限する仕組みになっています。

Docker Sandboxesを利用すると、たとえ環境変数を書き換えられて攻撃コードがmicroVM内で実行されても、ホスト側で共有されていない領域には直接アクセスできません。

Dockerが示した例では、攻撃によってPAGERが書き換えられて悪意のある処理が実行された場合でも、ホスト側のSSH秘密鍵ファイルはmicroVM内に存在しないため、攻撃コードが秘密鍵そのものを読み取って持ち出すことはできません。なお、標準設定では作業ディレクトリがホスト側と読み書き可能な状態で共有されるため、完全にすべてのデータから隔離されるわけではないとのこと。

DockerはAIエージェントが読み取るすべての指示を安全かどうか正確に判定しようとするよりも、AIエージェントが到達できる範囲をあらかじめ制限する方が有用だと述べています。