Copilotエージェントを企業が一括制御、利用者は許可を弱められない

GitHubは2026年9月9日、GitHub Copilot BusinessとGitHub Copilot Enterprise向けに、エージェント操作の権限を企業が集中管理する機能を一般提供した。GitHubの9月9日付発表 によると、管理者はシェルコマンド、ファイルの読み取りと編集、ネットワークドメインを、拒否、実行時の承認要求、プロンプトなしの許可に分類できる。

同機能は9月9日時点で対象プランに一般提供され、企業が定めた許可の境界は、利用者設定やワークスペース設定、自動承認、保存済みの承認では弱められない。翌10日の 独立系の機能報告 も、対象プラン、三段階の制御、利用者による上書きの禁止、Copilotアプリ、CLI、Agent Hostを使うVisual Studio Codeへの対応を確認している。

deny、ask、allowは厳しい規則が優先される

三つの処理区分は同列ではなく、deny、ask、allowの順に優先される。同じ操作が複数の規則に一致した場合、denyが一つでもあれば実行は阻止される。askに該当する操作には毎回新しい承認が必要で、過去の許可を再利用して通過させることはできない。

GitHubの管理設定リファレンス では、権限キーの優先関係と対象を指定するセレクターが定義されている。Shell(...)はシェルコマンド、Read(...)はファイルの参照、Edit(...)は書き込みと編集、Domain(...)はネットワーク接続先に対応する。シェルは完全一致またはコマンドの前方一致、ファイルはワークスペースやホームディレクトリなどを起点とするパスパターン、ドメインはサブドメインを含めたパターンで指定できる。

MDM、サーバー管理、ファイル配置のいずれかの設定元が権限規則を定義した場合、または適用対象の設定元がallowリストを宣言した場合、どの規則にも一致しない対応操作は原則として承認要求に回る。複数の設定元がallowリストを持つと、有効な許可範囲は和集合ではなく共通部分になる。一つの設定元が許可していても、別の設定元が許可していない操作まで自動実行の範囲は広がらない。

「すべて許可」の回避経路も閉じられる

permissions.disableBypassPermissionsModeを「disable」にすると、利用者は承認をまとめて省略するバイパスモードを有効にできない。Copilot CLIでは--yolo、--allow-all、個別の全許可オプションと対応するスラッシュコマンドが権限の引き上げに使えなくなる。Visual Studio Codeではグローバル自動承認が無効化され、GitHub Copilotアプリではセッション設定の「Allow all」が阻止される。

管理されたaskも単なる警告ではない。バイパスモード、自動承認、フックなどの承認ショートカット、以前に保存した許可では条件を満たせず、同じ操作が再度要求されれば改めて確認が出る。このため、一般利用者はdenyをallowへ変えられず、askを恒久的な承認に置き換えることもできない。

一方、企業は権限キーを上書き可能として明示した場合に限り、チーム別の設定で規則を置き換えられる。機密性の高いリポジトリを扱うチームと内部ツール担当に異なるポリシーを適用できるが、これは利用者による制限緩和ではなく、企業が許可した管理階層内での特化に当たる。

一般提供の対象は三つのクライアント環境

一般提供の対象として列挙されたのは、GitHub Copilotアプリ、GitHub Copilot CLI、Agent Hostを使用するVisual Studio Codeセッションだ。Visual Studio Codeでは、deny、ask、allowによる細かな規則はAgent Hostを使うセッションに限られる。ただし、バイパスモードを無効にする設定は、Agent Hostに限定されず、より広いVisual Studio Code環境でサポートされる。

JetBrains IDEとCopilot cloud agentは、今回の細かな権限規則の一般提供先には挙げられていない。したがって、企業は利用中のクライアント、Visual Studio CodeでのAgent Hostの有無、設定の配布経路を分けて確認する必要がある。管理設定を用意したことだけを理由に、未列挙の環境を含む全セッションへ同じ規則が適用されるとはみなせない。

初期ポリシーは操作の影響で三段階に分ける

導入時の実務的な出発点は、全操作を一律に止めることではなく、失敗時の回復可能性と外部への影響で分類することだ。次のチェックリストは公式リファレンスのセレクターと設定例を企業導入向けに整理したもので、すべての組織にそのまま適用する必須構成ではない。

1. 全許可の回避経路を閉じる。 permissions.disableBypassPermissionsModeをdisableにし、対象クライアントでバイパスが有効にならないことを確認する。
2. 破壊的操作と機密領域をdenyにする。 公式の設定例にはShell(rm -rf *)、Read(~/.ssh/**)、Edit(//etc/**)、未承認ドメインを対象にするDomain規則がある。削除、秘密情報の参照、システム領域の変更、管理外への接続を利用者判断で通さない境界になる。
3. 配布や外部共有につながる操作をaskにする。 設定例ではShell(git push *)、ソース領域の編集、特定APIドメインへの接続が挙げられている。該当するたびに、人が操作の意図と対象を確認できる。
4. 範囲が限定された反復処理をallowにする。 Shell(npm test *)、ソース領域の読み取り、承認済みパッケージレジストリへの接続は、条件が一致すれば追加確認なしで実行できる。
5. 競合規則と未一致操作を検証する。 複数区分に一致する操作、どの規則にも一致しない操作、保存済み承認がある操作を実行し、想定した優先順位で拒否または承認要求になるかを確かめる。

Domain規則は、エージェントが接続しようとするネットワークオリジンに対する権限を制御するもので、端末全体の通信隔離とは異なる。完全な外向き通信の境界が必要なら、管理対象のサンドボックス、資格情報の権限、ブランチ保護やレビューなど、別の制御も必要になる。

企業の最低権限は固定できるが、全環境共通ではない

今回の変更により、企業はCopilotのエージェント機能を全面停止せず、対応する操作ごとに最低限の権限境界を強制できるようになった。個人の自動承認や保存済み承認で企業のdenyとaskを迂回できないため、制御の強さを開発者ごとのローカル設定に依存させずに済む。

一方で、細かな規則が一般提供されたクライアント範囲には明確な境界があり、すべてのIDEやcloud agentに共通する仕組みではない。異なるクライアントが混在する企業では、各環境の対応状況とチーム別上書きの範囲を個別に確かめる必要が残る。