Copilot のローカルサンドボックスが GA、エージェントのファイル・通信・資格情報を制限

GitHub Copilot のエージェントが手元のマシンで実行するコマンドに、ファイル、ネットワーク、資格情報の境界を引ける。この「ローカルサンドボックス」が、2026年10月7日付の GitHub Changelog で一般提供（GA）になった。使えるのは Copilot CLI、GitHub Copilot app、Agent Host を使う VS Code のセッションの3つで、追加費用はかからない。

Copilot が起動したツールやコマンドは、開発者か組織が決めたポリシーに沿って、ファイルシステム、ネットワーク、資格情報、その他のシステム機能へのアクセスが絞られた状態で動く。組織は enterprise-managed settings でサンドボックスの必須化とポリシーの強制を設定できる。公式文書によるとローカルサンドボックスは既定では無効で、使うには有効化が必要だ。

絞れるのは4つの範囲

changelog に並んでいる制御対象を、読者が判断しやすい単位にまとめ直すと次のようになる。

対象	changelog の記述	読むときの注意
ファイルとディレクトリ	エージェントが実行するコマンドが読める・変更できるファイルとディレクトリを限定する	読み取りと変更の両方が対象
ネットワーク	インターネットとローカルネットワークへのアクセスを制御する	外部とローカルが別々に挙がっている
資格情報	Git の資格情報と GitHub CLI の資格情報へのアクセスを制御する	ほかの資格情報の扱いは書かれていない
ローカルのツール・サービス	ローカルの MCP サーバーや言語サーバーにもサンドボックスを適用する	「対応している場合」という条件付き

出典：GitHub Changelog「Local sandboxing for GitHub Copilot now generally available」（2026年10月7日）

実務で効きやすいのは資格情報の行だ。エージェントが走らせる git や gh のコマンドが手元の認証を使えるかどうかを、ポリシーの側で決められることになる。ただし changelog が名前を挙げているのは Git と GitHub CLI の資格情報だけで、クラウドの認証情報やほかのトークンが同じように扱われるかは書かれていない。

ローカル MCP と言語サーバーの行には「where supported」と条件が付いているが、対象サーバーの一覧は changelog にない。自分の環境で使っているサーバーがサンドボックスの内側で動くかは、個別に確かめる必要がある。

強制ポリシーと、許可されたセッション内の例外

組織がサンドボックスを必須にした場合、通常の設定や起動オプションで解除することはできない。ただし公式文書は、実効ポリシーが bypass を許す場合には、そのセッションの残りでサンドボックスを解除できると説明している。これは保存済みのポリシーを変更する操作とは別だ。

したがって「必須にしたから、すべてのコマンドが必ず制限内で動く」とは言い切れない。展開時は、必須化に加えてポリシーがセッション内の例外を許すかも確認したい。CLI と Copilot app のローカル設定は別々で、片方の有効化がもう片方に引き継がれることもない。

changelog はこの仕組みを、Copilot がアクセスできる範囲の境界をはっきりさせたまま、より自律的なエージェントのワークフローを採り入れるためのものと位置づけている。権限確認のたびに人が止める運用から、境界の内側では任せる運用へ移るときの土台になる。

モデルを替えても、効くのはツール実行の側

changelog は「モデルの実行」と「ツールの隔離」を別の関心事だと明記している。サンドボックスのポリシーは、Copilot がどのモデルを使っていてもツールの実行に適用される。同じ10月7日には Claude Haiku 5.5 が Copilot で GA になり、Copilot CLI では Pro、Pro+、Max、Business、Enterprise のユーザーがモデルピッカーから選べるが、モデルの切り替えでコマンドの境界が変わるわけではない。

裏返すと、サンドボックスはモデルに何が送られるかを制御するものとしては説明されていない。リポジトリ内のファイルをモデルに渡さない設定が必要なら、別の仕組みを見ることになる（Copilot app と CLI については コンテンツ除外の記事 で扱った）。

Windows・macOS・Linux で同じポリシーを使う

ローカルサンドボックスの中身は Microsoft eXecution Container（MXC）だ。共通のサンドボックスポリシーを、Windows、macOS、Linux それぞれの OS ネイティブの制御に変換する。共通のポリシーを使う設計だが、OS ごとに制約や必要条件は異なる。公式文書は、別の仮想マシンやコンテナではなく、OS のプロセス・ファイルシステム等の制限を使う方式と説明している。

CLI の組込みファイルツールは CLI 内で動くため、OS のサンドボックスがその操作を直接制限するわけではない。これらのツールは設定を best-effort で確認する。シェルコマンドに対する OS の制限と、組込みツールによる設定確認を分けて評価する必要がある。

有効にする前に決めておくこと

詳細な設定は公式文書で確認できる。事前に決める制御対象は次のように整理できる。

• エージェントに書き込ませてよいディレクトリはどこまでか（リポジトリの外を含めるか）
• 依存関係の取得などでインターネットが要るか、社内のローカルネットワークには出させるか
• エージェントに git push や gh の操作をさせるか、資格情報を渡さないか
• 使っているローカル MCP サーバーと言語サーバーが、サンドボックスの対象になるか

組織で揃えるなら、これを enterprise-managed settings で強制する範囲と、開発者に任せる範囲に分けておくと、展開後に許可範囲や例外の扱いを問い合わせに対して説明しやすい。