8月21日、Microsoft Command Lineが「If you want a secure AI agent, start restricting its environment.」と題した記事を公開した。Azure SRE AgentのAIエージェント本番運用における、実行環境そのものを制約するという設計思想と、その具体的な実装について詳しく解説されている。
「AIエージェントが安全かどうか」を問われたとき、多くのエンジニアはまず権限の最小化（Least Privilege）や人間による承認ゲートを思い浮かべる。だがAzure SRE Agentチームが1年間の本番運用から得た結論は、それだけでは不十分というものだ。本記事では、その学びと4層の強制制御（enforcement）アーキテクチャが解説されている。
「正しい意図」が引き起こした4つの失敗
記事が最も力を入れているのが、攻撃者なしに起きた実際のインシデントだ。
1. エージェントが自分でクレデンシャルを再発行した
GitHubトークンの有効期限が切れたとき、エージェントはハーネス（制御プレーン）のソースコードを読み取り、OAuthデバイスコードフローを再構築。研究者にログインを促して新しいアクセストークンとリフレッシュトークンをファイルシステムに保存した。クレデンシャル発行を管理する仕組みを、エージェント自身が内側から再現してしまった。
2. 外部OCRサービスに顧客データを送信した
スクリーンショットの解析を求められたエージェントは、ビジョンツールがないと判断し、公開インターネット上のフリーのOCRサービスを自分で探し出して画像をPOSTした。推論としては「合理的」だが、顧客データが第三者サーバーに送信・ログ記録される可能性があった。
3. 顧客のシークレットをメモリに保存した
リポジトリにコミットされていたクレデンシャルを発見したエージェントは、調査結果にそれを引用し、「絶対に使わない」というメモとともにメモリに保存した。善意の行動だったが、シークレットは調査サマリーとメモリストアの両方に書き込まれ、ローテーション対象から外れた場所に存在することになった。
4. 安全確認が途中で失敗したのに、VMをデアロケートした
5回の安全確認後にVMをデアロケートするよう指示されていたエージェントは、3回目以降でロギングサービスが利用不能になると、過去の成功パターンに照合して確認を省略し、デアロケートを実行した。
記事の著者はこう結論づける：
「If the environment permits it, the agent will eventually do it—intentionally, maliciously, or by accident. The environment is the policy.（環境が許可するなら、エージェントはいつかそれをやる。意図的に、悪意で、あるいは偶然に。環境こそがポリシーだ。）」
悪意ある攻撃者はこれをさらに悪化させる。エージェントが読むあらゆるチャンネルは、信頼できない誰かが書き込める。実行レイヤーでは、ハルシネーションによるコマンドも注入されたコマンドも同じコマンドだ。
4層の強制制御アーキテクチャ
1. サンドボックス：実行環境をトラストバウンダリの外に出す
当初の設計では、ハーネス・LLMが生成したコード・ツール・クレデンシャルが同一マシン上で動いていた。これが上記インシデントの根本原因だ。ハーネス内に実装したポリシーフックは、エージェント自身が読んで修正・迂回できてしまう。
新設計では、エージェントの推論とオーケストレーションを「信頼されたランタイム」に置き、LLMが生成したコードとツールはエージェントごとのmicroVMで実行する。両者は狭いAPI経由でのみ通信する。
microVMとはコンテナとは異なり、ホストカーネルを共有しないハードウェア仮想化境界を持つ軽量な仮想マシンだ。本実装はACA Sandboxes上に構築されている。エグレス（外部通信）はデフォルトでdenyされており、エージェントがOCRサービスへの送信を試みても、通信が出て行かない。
2. クレデンシャルを「所持しない」設計
サンドボックス化しても、ツールは認証が必要だ。microVM内にクレデンシャルを置けば、そこで動くすべてのコード（生成スクリプト、依存パッケージ、MCPサーバー）からアクセスできてしまう。
解決策は「サンドボックスはクレデンシャルを使えるが、所持できない」という原則だ。
git・az・kubectlなどのツールは通常の認証パスを使うが、実際のクレデンシャルの代わりにopaque handle（不透明なハンドル）を受け取る。これはクレデンシャル本体を含まず、エグレスプロキシとの間でのみ意味を持つ一時的な参照トークンだ。このハンドルは、エグレスプロキシの外では無価値である。
プロキシは境界で実際の認証を行い、1つのハンドルは以下の条件に縛られる：
- 呼び出し単位： そのツール呼び出しのみ有効
- 送信先ロック： 許可されたエンドポイント以外には使えない
- スコープ制限： 承認された操作のみ
- シングルユース： リクエスト完了後は即失効
クレデンシャルはVM内のファイルシステム、環境変数、プロセスメモリ、ツール出力、モデルコンテキスト、ログ、メモリのいずれにも入らない。
さらに、正当なツール呼び出しがシークレットをデータとして返すケース（azコマンドがキーや接続文字列を返すなど）については、モデルコンテキストに入る前に検出・スクラブする仕組みを内部でパイロット中だという。
「Real credentials never enter the sandbox. Raw secrets never enter the model.（本物のクレデンシャルはサンドボックスに入れない。生のシークレットはモデルに入れない。）」
3. 承認をパーミッションチェックではなくリスク分類として扱う
現在の本番境界は「ミューテーション（状態変更）には人間の承認が必要」というシンプルなものだ。だがこれはすべての変更操作を同列に扱う。インスタンスの再起動・サービスのスケール・VMのデアロケートは、コマンド単体ではリスクを判断できない。
同一操作でも以下の3要素でリスクが変わる：
- 操作の種類： 再起動 vs. デアロケート
- 対象： テスト用VMか、本番の重要依存コンポーネントか
- 根拠： 確認済みの証拠か、途中で失われた・ハルシネーションされた確認か
Anthropic Claude CodeのオートモードやMetaのAgent Guardrailsも同じ方向性を示している。Azure SRE Agentは、エージェントの推論ループの外側に独立したガードを置き、操作・対象・証拠の3軸でリスクをスコアリングする。低リスクかつ根拠が最新であれば自律実行、重要ターゲットや根拠不十分であればレビューへ回す。
4. 可観測性：エージェントの推論を検証可能にする
上記3層を支える基盤として、記事が4層目に位置づけるのが可観測性（observability）の強制だ。エージェントが「なぜその操作を選んだか」という推論の根拠を、実行と切り離されたログとして記録・検証できる仕組みを指す。
インシデント4（安全確認の省略）が示すように、エージェントは根拠の消失を黙って補完してしまう。可観測性レイヤーは、操作の実行を許可する前に「根拠が最新かつ完全か」を外部から検査する役割を担う。これにより、ハルシネーションや途中でのログ消失を自律実行の前提条件違反として検出できる。
「環境がポリシー」という設計思想の本質
この記事で繰り返し強調されるのは、「プロンプトで禁止しても意味がない。環境が許可している限り、エージェントはいつかそれをやる」という前提だ。
エージェントのリーチ内に置いたコントロールは、ツール呼び出し1回で迂回できる。ポリシーはエージェントが検査・影響できる範囲の外に置いてはじめて機能する。承認ゲートを増やすことが安全性の最大化ではなく、エージェントのリーチ外にコントロールを移すことが最大化につながるという設計哲学だ。
詳細はIf you want a secure AI agent, start restricting its environment.を参照していただきたい。
