GitHub、エージェントツールの権限判定を企業ポリシーに統一。ただしソフトウェアルールはOSレベルの隔離ではない

GitHubはCopilot BusinessおよびEnterprise向けに「managed permissions」の一般提供を開始した。管理者は共通のルールを使い、Copilot App、Copilot CLI、さらにAgent Hostを採用したVS Codeセッションを制御できる。現在、ルールでは`Shell`、`Read`、`Edit`、`Domain`の4種類の操作を照合し、それぞれを`deny`、`ask`、`allow`に設定できる。企業はエージェントモードを全面的に無効化することなく、チームごとに異なるポリシーを適用することも可能だ。

今回のアップデートは、エージェントのフロントエンドで起こりがちな権限のドリフトに対処するものだ。ユーザーが以前保存した承認、ワークスペース設定、`allow-all`、自動承認によって、中央管理の制限を弱めることはできない。VS Codeのパブリックプレビューでは、評価の優先順位は拒否、確認、許可の順で、どのルールにも一致しない操作ではデフォルトで確認が求められる。パスルールでは、ワークスペース、カレントディレクトリ、ホームディレクトリ、ファイルシステムのルートを区別できる。ドメインも個別に許可リストまたは拒否リストへ登録できるため、認証情報ディレクトリのブロック、`git push`の制限、社内パッケージレジストリのみへのアクセス許可といった用途に適している。

重要なのは、managed permissionsがAgent Host／Copilot SDKによってツール呼び出し層で適用されるポリシーであり、カーネルやコンテナによる強力な隔離と混同すべきではない点だ。GitHub自身のCLIドキュメントでも、Shellコマンドはソフトウェアのインストール、ファイルの削除、コードのプッシュ、ネットワークリクエストの送信を実行できると説明されている。管理ルールでコマンド実行が許可されている場合、その実際の能力は、プロセスが持つホスト上の権限と、ローカルまたはクラウドのサンドボックスが別途有効になっているかどうかに左右される。この点は、先ごろJetBrainsに追加された企業向けサンドボックスとも異なる。前者はエージェントが特定の操作を試行できるかを決定し、後者は起動済みのプロセスが実際にアクセスできるリソースを制限する。

導入担当者はまず最小限のルールセットを用いて、ワイルドカード、シンボリックリンク、ワークスペースルートの解決、コマンドラッパーを検証し、拒否イベントを監査対象に含めるべきだ。今後の注目点は、MCPツール、ブラウザ操作、サブエージェントを同じ権限構文へ組み込めるか、そして各プラットフォームで一貫した強制適用のセマンティクスが維持されるかどうかである。