GitHub、Copilotエージェントの操作権限をエンタープライズ側で一括統制

何が発表されたか

• 2026年9月9日、GitHub が Copilot エージェント操作のエンタープライズ管理権限（enterprise managed permissions） を一般提供開始した。
• 管理者は、各操作を ブロック（deny）／人間の承認を必須（ask）／プロンプトなしで実行可（allow） の3段階で中央指定できる。
• 対象となる操作カテゴリは シェルコマンド、ファイルの読み取り・編集、ネットワークドメイン の3つ。
• エンタープライズ内のチームごとに個別ポリシーを設定できる。
• 重要な点として、この制限は ユーザー設定・ワークスペース設定・自動承認機能・過去に付与済みの承認では回避できない。
• 対象は GitHub Copilot app、GitHub Copilot CLI、Agent Host を使う Visual Studio Code セッション。プランは Copilot Business と Copilot Enterprise。

開発者への影響

エージェント型コーディングツールの社内導入で、これまで最大の障壁だったのが「情シスが許可を出せない」という一点だった。個人の設定でいくらでも緩められる状態では、セキュリティレビューを通せないからである。今回の変更は、まさにその穴を塞ぐものだ。

受託側にとっては、提案の順番が変わる。従来は「まず個人で試してもらい、良ければ全社へ」という進め方だったが、これからは「エンタープライズ側の deny/ask/allow ポリシーをどう引くか」を最初の設計項目として持ち込める。特にネットワークドメインの許可リストは、クライアントの機密情報が外部に出ないことを説明する材料になるため、提案書のセキュリティ章がそのまま書ける。

自分の受託環境で気をつけたいのは逆方向で、クライアントのエンタープライズポリシー下では、手元で動いていたエージェント運用が動かなくなる可能性があるという点。常用しているシェルコマンドや外部APIのドメインが ask に落ちていると、自動実行前提のワークフローが毎回止まる。案件開始時に、対象組織のポリシーを確認してから作業設計を組むのが安全である。

利用条件

GitHub Copilot Business / GitHub Copilot Enterprise で利用可能。設定は enterprise managed settings の deny/ask/allow ドキュメントに記載されている。