GitHub CLIの旧PGP鍵が失効、Linux更新停止を新鍵で直す
実践ガイド 16
AIエージェントの権限をOCI化、Docker仕様は「許可」を運べる
Dockerは 2026年9月24日にSandbox Kit Specification v3をApache 2.0で公開 した。AIエージェントやツールの実行内容と、ネットワークや認証情報などの権限要求を通常のOCIイメージにまとめる仕様で、現段階では実験的なものとされている。
この成果物が運ぶ「許可」は、正確にはホストに対する権限要求だ。Dockerの設計解説 は、ホストが要求を判断し、仕様に対応するランタイムが通信の遮断や認証情報の注入を担うと説明する。宣言を読まない環境では、同じイメージを取得できても権限規則は強制されない。
実行内容と権限要求を一つのOCIイメージに収める
Kitは独自の配布形式ではなく、通常のOCIイメージとして作られる。エージェントやツールの内容はイメージのレイヤーに入り、権限などの宣言はマニフェストのアノテーションに入る。イメージのダイジェストを固定すれば、内容と宣言を同じ版として指定できる。
従来は接続先、マウント、認証情報の設定が起動引数や別の設定ファイルに分かれ、実行するソフトウェアだけを見ても必要な権限が分かりにくかった。Kitでは要求が成果物と一緒に移動するため、別の環境へ渡す際にも、何を実行し何へのアクセスを求めるかを一体として確認できる。既存のレジストリに保存できることは、そのレジストリや一般のOCIランタイムが要求を審査・強制することまでは意味しない。
記述の元になるのはYAMLのディスクリプターだ。DockerのKit公式文書 によると、ネットワークアクセス、認証情報、セットアップコマンド、エージェントへの指示を指定でき、機能の提供状態はEarly Accessである。Kitには、実行環境と起動コマンドを与えるworkloadと、ツールや設定を重ねるmixinがある。サンドボックスはworkloadを基礎に、必要なmixinを組み合わせて構成する。
GitHub CLIの例は、APIの操作まで絞り込む
公開されたGitHub CLI用mixinの例では、github.comとapi.github.comへの接続を要求する一方、APIに対しては許可するHTTPメソッドを列挙している。さらにapi.github.comの/repos/**という経路にはDELETEを拒否する規則を置く。広い許可規則にDELETEが含まれていても、この経路では拒否規則が優先する。
この区別により、エージェントにGitHub APIを使わせながら、リポジトリ配下への削除要求を同じ扱いで通さずに済む。単に「GitHubへの接続を許可する」と書くより、接続先、操作の種類、対象経路を狭く表せる点が例の要点だ。ただし、mixinの宣言だけが通信を止めるわけではない。ホストが要求を受け入れ、対応ランタイムが通信に規則を適用して初めて拒否が働く。
Kitが求めるものには、ネットワーク規則のほか、ボリューム、ポート、デバイスなども含まれる。いずれもエージェントが自分で獲得する権限ではなく、実行環境に提示する要求として扱う。仕様が権限の内容を持ち運べるようにしたことと、どのホストでも同じ権限が自動的に与えられることは異なる。
認証情報は代理注入でき、必須要求には停止条件がある
同じGitHub CLI用mixinは、認証情報をプロキシが管理する形も示している。対応ランタイムは指定された宛先へのリクエストに実際の値を注入し、サンドボックス内のエージェントには代替値を見せる。これにより、認証付きのAPI呼び出しに必要な値を使わせつつ、トークンの実値をエージェントの環境へ直接渡さない構成を記述できる。
例の認証情報要求は任意として記述されている。これに対し、Kitが必須とした要求をホストが満たせない場合、仕様は起動を拒否する。たとえば必須の制御を提供できないままエージェントを開始すれば、Kitが表した条件と実際の環境が食い違う。停止条件は、その食い違いを黙って受け入れないための境界となる。
mixinを重ねると、権限要求も合成される
mixinはツールを再利用しやすくするが、追加したmixinの要求も完成した環境に加わる。あるmixinがAPI接続を、別のmixinが別の接続先や認証情報を求めれば、確認すべき対象は各mixin単体ではなく、組み合わせた後の要求集合だ。ネットワーク規則は合成されるため、ツールの追加がアクセス範囲の拡大につながり得る。
仕様は依存関係を解決してKitを組み合わせ、必要な要素が欠ける場合や両立しない定義がある場合にはエラーにする。Kitをまとめた集合も一つの成果物として公開できるが、まとめることで個々の要求が消えるわけではない。配布する版にどの権限要求が含まれるかが、引き続き重要になる。
更新時には、新しい接続先や認証情報の要求を差分として表せる。仕様は要求を正規化した集合として比較する方法を定めており、更新承認に対応したランタイムなら、権限が広がる変更を保留できる。拒否規則の削除も拡大に当たる。一方、差分を記述できることだけで更新が自動的に止まるわけではなく、その判断と停止もランタイムの実装に依存する。
仕様の公開と、各環境での強制は別段階
Docker Sandboxesは、この仕様に対応する最初のランタイムとして示されている。仕様にはKitの成果物とランタイムの適合性を確かめる仕組みもあるが、通常のOCIイメージを扱える環境すべてがKitのアノテーションを解釈するわけではない。解釈しない環境では宣言がイメージとともに残っても、そこに書かれた拒否規則は実行時の制御にならない。
公開によって定まったのは、AIエージェントの実行内容と外部への権限要求を結び付けて配布する形式と、対応ランタイムが果たすべき役割だ。仕様はなお実験段階にあり、ほかのランタイムが各要求をどこまで実装するかは今後の対応を待つ。現時点の境界は明確で、Kitは必要な権限を宣言し、その許可・拒否を実行するのはホストと対応ランタイムである。
関連記事:
関連記事
ニュースレターを購読
Web3、AI、暗号資産の最新ニュースを受信箱にお届けします。
0