GitHub CopilotでMCPサーバーが突然ブロックされた場合は、まずdeniedMcpServersへの一致、allowedMcpServersへの不一致、別のポリシー層による制限、URL・コマンド内の未解決変数、JSONの構文不正を確認してください。
GitHub Copilot EnterpriseのMCP許可・拒否リストは拒否を優先し、複数の許可リストすべてを通過したサーバーだけを実行する仕組みです。さらに、設定を正しく検証できない場合はFail Closedとなり、組み込みの既定サーバーを除くMCPサーバーがブロックされます。
2026年8月6日に一般提供されたallowedMcpServersとdeniedMcpServersを使うと、リモートURL、ローカルコマンド、サーバー名を基準に、GitHub Copilotクライアントで実行できるMCPサーバーを企業全体で管理できます。発表時点ではGitHub Copilot app、Copilot CLI、VS Codeでの適用が明示されています。(The GitHub Blog)
GitHub CopilotでMCPサーバーがブロックされる主な条件
CopilotのMCP許可・拒否リストでは、次の順序で実行可否が決まります。
| 判定条件 | 結果 |
|---|---|
| GitHubが提供する組み込みの既定MCPサーバーである | 原則として許可 |
deniedMcpServersのいずれかに一致する | ブロック |
allowedMcpServersが定義されているが、どのエントリにも一致しない | ブロック |
| URLやコマンドに未解決の環境変数が残っている | ブロック |
| 許可・拒否リストのJSONや構造が不正 | 空の許可リストとして扱われ、組み込み以外をブロック |
| 複数の設定ソースのうち、1つでも拒否している | ブロック |
| 複数の許可リストのうち、1つでも通過できない | ブロック |
拒否リストは許可リストよりも優先されます。許可リストが複数存在する場合は共通部分だけが許可され、拒否リストが複数存在する場合はすべての拒否条件が合成されます。(GitHub Docs)
MCPサーバーが動かないときは、次の順番で調べると原因を絞り込みやすくなります。
- 「MCP servers in Copilot」ポリシーが有効か
- 使用中のクライアントがポリシーに対応しているか
- 実際のURLまたは起動コマンドが許可リストと完全に一致しているか
- サーバー管理、MDM、ローカルファイルの各ポリシーをすべて通過しているか
- JSON、環境変数、チーム設定に不正がないか
allowedMcpServersとdeniedMcpServersとは
MCPは、生成AIモデルと外部のデータソースやツールを接続するための標準プロトコルです。GitHub CopilotではMCPサーバーを追加することで、社内API、データベース、ブラウザー操作、ファイル処理などの機能をエージェントから利用できるようになります。(GitHub Docs)
一方、MCPサーバーは外部データへのアクセスやコマンド実行能力を持つことがあります。開発者が任意のサーバーを追加できる状態では、未承認サービスへの情報送信や、意図しないローカルコマンドの実行につながる可能性があります。
GitHub Copilot Enterpriseでは、エンタープライズ管理設定のmanaged-settings.jsonに次のキーを追加し、実行可能なMCPサーバーを制限できます。
allowedMcpServers
実行を許可するMCPサーバーを定義します。
このキーを設定すると、いずれかのエントリに一致したサーバーだけが許可されます。一致しないサーバーは自動的にブロックされます。
deniedMcpServers
無条件にブロックするMCPサーバーを定義します。
同じサーバーがallowedMcpServersにも一致していたとしても、deniedMcpServersに一致すればブロックされます。
省略と空配列では意味が異なる
| 設定 | 動作 |
|---|---|
allowedMcpServersを省略 | 拒否リストに該当しないMCPサーバーを許可 |
"allowedMcpServers": [] | 組み込みの既定サーバーを除き、すべてブロック |
deniedMcpServersを省略 | 拒否リストによる追加制限なし |
"deniedMcpServers": [] | 拒否リストによる追加制限なし |
| 許可・拒否の両方を設定 | 許可リストに一致し、かつ拒否リストに一致しないサーバーのみ許可 |
重要なのは、拒否リストだけを設定してもデフォルト拒否にはならないことです。
承認したMCPサーバーだけを実行させたい場合は、deniedMcpServersだけではなく、allowedMcpServersを明示的に設定してください。空の許可リストは、組み込みの既定サーバーを除くすべてのサーバーをブロックします。(GitHub Docs)
組み込みのGitHub MCPサーバーはブロックできない
組み込みのGitHub MCPサーバーなど、信頼されたGitHubのファーストパーティサーバーは許可・拒否リストの対象外です。
そのため、次の設定は「MCPを完全にゼロにする」設定ではありません。
{
"allowedMcpServers": []
}この設定でも、GitHubが組み込みで提供する既定MCPサーバーは利用できる場合があります。deniedMcpServersに組み込みGitHub MCPサーバーを指定してもブロックできません。(GitHub Docs)
MCPサーバーを識別する3種類のマッチャー
allowedMcpServersとdeniedMcpServersでは、次の3種類のマッチャーを利用できます。
| マッチャー | 対象 | 一致方法 | 推奨用途 |
|---|---|---|---|
serverUrl | HTTP・SSEのリモートMCPサーバー | URLで照合。*を使用可能 | リモートサーバーの正式な制御 |
serverCommand | stdio形式のローカルMCPサーバー | コマンドと全引数を完全一致 | ローカルサーバーの正式な制御 |
serverName | 名前を持つMCPサーバー | ユーザーが設定した名前と完全一致 | 補助的な識別、インメモリサーバー |
各エントリには、マッチャーを1種類だけ指定します。
次のように、1つのオブジェクトへserverUrlとserverNameを同時に入れないでください。
{
"serverUrl": "https://mcp.example.com/*",
"serverName": "company-mcp"
}正しくは、それぞれを別のエントリとして定義します。
{
"allowedMcpServers": [
{
"serverUrl": "https://mcp.example.com/*"
},
{
"serverName": "company-mcp"
}
]
}ただし、サーバーの真正性を強く確認したい場合は、ユーザーが変更できるserverNameではなく、serverUrlまたはserverCommandを使用してください。(GitHub Docs)
serverUrlでリモートMCPサーバーを制御する
serverUrlは、HTTPまたはSSEで接続するリモートMCPサーバーをURLで識別します。
{
"allowedMcpServers": [
{
"serverUrl": "https://mcp.example.com/*"
}
]
}*ワイルドカードは、サブドメインやパスの範囲指定に使用できます。
{
"allowedMcpServers": [
{
"serverUrl": "https://*.internal.example.com/*"
}
]
}ただし、必要以上に広いパターンを指定すると、未審査のサーバーまで許可する可能性があります。
例えば、組織内のすべてのサブドメインを許可するのではなく、MCP専用ホストやパスに絞る方が安全です。
{
"serverUrl": "https://mcp.internal.example.com/approved/*"
}URLは照合前に正規化されます。スキームとホストの小文字化、国際化ドメイン名のPunycode変換、既定ポートの削除、ホスト部分のパーセントエンコード解除などが行われ、表記の違いを使った回避が抑制されます。(GitHub Docs)
Copilot CLIではスキームとホストの照合は大文字と小文字を区別しませんが、パス部分は区別されます。次のような違いがある場合は注意してください。(GitHub Docs)
https://mcp.example.com/Approved/
https://mcp.example.com/approved/serverCommandでローカルMCPサーバーを制御する
serverCommandは、標準入力・標準出力を使うstdio形式のローカルMCPサーバーを、起動コマンドと引数で識別します。
{
"allowedMcpServers": [
{
"serverCommand": [
"npx",
"-y",
"@example/mcp-server"
]
}
]
}serverCommandは、コマンドだけでなく引数の内容と順序も完全一致する必要があります。ワイルドカードやシェルによるコマンドライン展開は利用できません。(GitHub Docs)
例えば、次の2つは別のコマンドとして扱われます。
npx -y package-name
npx package-name次の2つも一致しません。
npx -y package-name --readonly
npx -y package-nameWindowsでは、cmd /cやPowerShellなどのラッパーも含めて照合されます。
{
"serverCommand": [
"cmd",
"/c",
"uvx",
"markitdown-mcp"
]
}開発端末側が次のように直接実行している場合、上記の許可ルールには一致しません。
uvx markitdown-mcpローカルMCPサーバーを許可する前に、利用者の設定ファイルから実際のコマンド配列を取得し、文字列、引数、順序、実行ラッパーを確認してください。
serverNameはセキュリティ境界にしない
serverNameは、ユーザーがMCPサーバーに付けたラベルと完全一致します。
{
"allowedMcpServers": [
{
"serverName": "approved-server"
}
]
}サーバー名はユーザーが変更できるため、信頼できるサーバーの同一性を保証する目的には向きません。
例えば、不正なサーバーにapproved-serverという名前を付けても、名前だけでは本物かどうかを判断できません。GitHubも、サーバーのIDを強制する必要がある場合はserverUrlまたはserverCommandを使用するよう案内しています。(GitHub Docs)
serverNameは、URLやコマンドを持たないインメモリサーバーを管理する場合や、補助的な分類に使用するのが適しています。
Fail Closedで設定不正時はMCPサーバーが停止する
CopilotのMCP許可・拒否リストは、設定を安全に検証できない場合に許可側へ倒すのではなく、ブロック側へ倒すFail Closed方式です。
Fail Closedが発生する代表例
- JSONのカンマや括弧が不正
allowedMcpServersが配列ではない- 1つのエントリに複数のマッチャーが入っている
- マッチャーに想定外のデータ型が入っている
- URLやコマンドの環境変数を解決できない
- クライアントがサーバーのURLまたはコマンドを検証できない
許可・拒否リストが不正な場合、クライアントはそのポリシーを空のallowedMcpServersとして扱います。その結果、組み込みの既定サーバーを除くMCPサーバーがブロックされます。(GitHub Docs)
例えば、次のJSONは末尾のカンマがあるため不正です。
{
"allowedMcpServers": [
{
"serverUrl": "https://mcp.example.com/*"
},
]
}本番環境でこのような設定を配布すると、意図した1台だけではなく、対象となる追加MCPサーバーがまとめて利用できなくなる可能性があります。
未解決の環境変数もブロックの原因になる
MCPサーバーのURLやコマンドには、環境変数を使う構成があります。
{
"serverUrl": "https://${MCP_HOST}/api"
}クライアントでMCP_HOSTを解決できれば照合できますが、変数が未定義のまま残るとサーバーはブロックされます。
https://${MCP_HOST}/api$VARIABLEや${VARIABLE}などの未解決参照が残っていないか、対象ユーザーの実行環境で確認してください。(GitHub Docs)
複数ポリシー層では許可リストの共通部分だけが有効
エンタープライズ管理設定は、次のような複数の方法で配布できます。
| 配布方法 | 主な用途 |
|---|---|
| サーバー管理 | .github-privateリポジトリから企業・チーム単位で配布 |
| MDM管理 | WindowsやmacOSの管理端末へデバイス単位で配布 |
| ファイルベース | Linux、コンテナ、Codespacesなどへ設定ファイルを直接配置 |
クライアントが複数の設定ソースを受け取った場合は、どれか1つが優先されて他が無視されるのではなく、すべての制限が適用されます。(GitHub Docs)
許可リストと拒否リストの合成は、次のように考えると分かりやすくなります。
有効な許可範囲
= すべてのallowedMcpServersの共通部分
有効な拒否範囲
= すべてのdeniedMcpServersの和集合複数層の判定例
| サーバー管理 | MDM管理 | ファイル管理 | 結果 |
|---|---|---|---|
| 許可 | 許可 | 設定なし | 許可 |
| 許可 | 許可リストに存在しない | 設定なし | ブロック |
| 許可 | 許可 | 拒否 | ブロック |
| 設定なし | 許可 | 設定なし | 許可 |
| 許可 | JSON不正 | 設定なし | 組み込み以外をブロック |
例えば、サーバー管理の許可リストに次の設定があるとします。
{
"allowedMcpServers": [
{
"serverUrl": "https://mcp.example.com/*"
}
]
}MDM側が次のようになっている場合、mcp.example.comはMDMの許可リストに含まれないため実行できません。
{
"allowedMcpServers": [
{
"serverUrl": "https://security-mcp.example.com/*"
}
]
}片方の許可リストに登録しただけでは不十分です。対象端末に適用されるすべてのポリシー層を調べてください。
GitHub Copilot EnterpriseのMCP許可・拒否リスト設定例
承認済みサーバーだけを許可する基本設定
次の例では、指定したリモートサーバーとローカルサーバーだけを許可し、ルートファイルシステムへアクセスする特定のローカルサーバーを拒否します。
mcp.example.comは説明用の予約ドメインであり、実際の社内MCPサーバーURLに置き換えてください。コマンド例はGitHub公式ドキュメントの構成例を基にしています。(GitHub Docs)
{
"allowedMcpServers": [
{
"serverUrl": "https://mcp.example.com/*"
},
{
"serverCommand": [
"npx",
"@playwright/mcp@latest"
]
},
{
"serverCommand": [
"cmd",
"/c",
"uvx",
"markitdown-mcp"
]
}
],
"deniedMcpServers": [
{
"serverCommand": [
"npx",
"-y",
"@modelcontextprotocol/server-filesystem",
"/"
]
}
]
}この設定では、許可リストにない追加MCPサーバーは実行できません。
また、ファイルシステムサーバーが何らかの許可エントリにも一致していたとしても、拒否リストに指定したコマンドと完全一致すればブロックされます。
拒否リストだけを設定する例
次の設定は、指定したコマンドだけをブロックします。
{
"deniedMcpServers": [
{
"serverCommand": [
"npx",
"-y",
"@modelcontextprotocol/server-filesystem",
"/"
]
}
]
}allowedMcpServersが存在しないため、それ以外のMCPサーバーは原則として許可されます。
緊急的に危険なコマンドを止める用途には使えますが、承認済みサーバーだけに限定する用途には不十分です。
組み込み以外をすべてブロックする例
{
"allowedMcpServers": []
}新しいMCPサーバーを審査するまで追加サーバーを全面停止したい場合に使えます。
ただし、組み込みの既定サーバーは対象外です。
チームごとに許可リストを変える例
サーバー管理方式では、overridableを使ってチームごとの値を設定できます。
エンタープライズのcopilot/managed-settings.jsonでは、チームによる上書きを許可するキーを次のように定義します。
{
"allowedMcpServers": {
"overridable": [
{
"serverUrl": "https://mcp.example.com/*"
}
]
}
}copilot/team-mappings.jsonで、チームと設定ファイルを関連付けます。
{
"data-platform.json": [
"data-platform"
]
}copilot/teams/data-platform.jsonへ、対象チームの設定を記述します。
{
"allowedMcpServers": [
{
"serverUrl": "https://data-mcp.example.com/*"
}
]
}チーム設定が存在しない場合は、overridable内の既定値が使われます。チーム固有の値を設定しても、MDMやファイルベースなど、別の管理ソースによる制限は回避できません。(GitHub Docs)
複数チームに所属するユーザーでは設定が合成されるため、単一チームのテストユーザーだけでなく、複数チームへ所属するユーザーでも動作確認してください。
MCP許可・拒否リストを導入する手順
現在使用しているMCPサーバーを棚卸しする
最初から許可リストを作るのではなく、現在の利用状況を調べます。
最低限、次の情報を収集してください。
- 利用目的
- 管理責任者
- リモートかローカルか
- 接続先URL
- 起動コマンドと全引数
- 使用する認証情報
- アクセスする社内データ
- 書き込み操作の有無
- 利用チーム
- パッケージやコンテナの更新方法
serverCommandは引数まで完全一致するため、「Playwrightを使っている」といった製品名だけでは設定を作れません。開発者が実際に使用しているMCP構成から、コマンド配列をそのまま取得してください。
「MCP servers in Copilot」ポリシーを有効にする
許可リストを設定しても、Copilot側でMCPサーバーの利用自体が無効になっていれば実行できません。
MCPを利用させるエンタープライズまたは組織で、「MCP servers in Copilot」ポリシーが有効になっていることを確認してください。(GitHub Docs)
既存のカスタムレジストリ制限を確認する
すでにカスタムMCPレジストリを使い、「レジストリに登録されたサーバーだけを許可する」ポリシーを設定している場合、managed-settings.jsonの許可リストと重複して判定される可能性があります。
GitHubは、managed-settings.jsonを許可リストの中心にする場合、レジストリによる制限を「Allow all」に変更し、必要に応じてMCP Registry URLを削除することを推奨しています。(GitHub Docs)
レジストリはサーバーを発見しやすくする仕組みとして利用し、実行制御はmanaged-settings.jsonへ集約すると、原因調査がしやすくなります。GitHubも、管理設定ファイルによる許可リストを、カスタムレジストリより強い適用方式として案内しています。(GitHub Docs)
managed-settings.jsonを作成する
サーバー管理方式では、source organizationの.github-privateリポジトリに次のファイルを作成します。
copilot/managed-settings.json設定を追加したら、既定ブランチへコミットします。(The GitHub Blog)
JSONをコミット前に検証する
Fail Closedによる一斉停止を防ぐため、Pull RequestやCIでJSON検証を行います。
jqを利用できる環境では、次のコマンドで構文を確認できます。
jq empty copilot/managed-settings.jsonPowerShellでは、次のように確認できます。
Get-Content .\copilot\managed-settings.json -Raw |
ConvertFrom-Json |
Out-Null構文確認だけでは、コマンドやURLが実際のMCP設定と一致しているかまでは判定できません。次の情報もレビュー対象にします。
- 各エントリにマッチャーが1つだけ入っているか
- URLのパスやワイルドカードが広すぎないか
serverCommandの引数と順序が正しいか- 環境変数が全対象端末で定義されているか
- 既存のMDM・ファイルベース設定と矛盾しないか
少人数のパイロットグループへ適用する
いきなり全社へ適用せず、少人数の端末やエンタープライズチームで検証します。
少なくとも次のテストを実施してください。
| テスト | 期待する結果 |
|---|---|
| 許可リストに登録したリモートMCPサーバー | 起動できる |
| 許可リストに登録したローカルMCPサーバー | 起動できる |
| 許可リストにないサーバー | ブロックされる |
| 許可と拒否の両方に一致するサーバー | ブロックされる |
| 引数を1つ変更したローカルコマンド | ブロックされる |
| 複数の設定ソースすべてで許可したサーバー | 起動できる |
| 1つの設定ソースだけで未許可のサーバー | ブロックされる |
構文不正によるFail Closedの試験は、本番利用者へ影響しない隔離されたテスト環境でのみ行ってください。
設定が反映されたことを確認する
サーバー管理方式の設定は、対応クライアントへ通常1時間程度で反映されます。クライアントの再起動や再サインインにより、すぐに更新を取得できる場合があります。(GitHub Docs)
| 配布方式 | 更新確認の目安 |
|---|---|
| サーバー管理 | 通常は約1時間。再起動または再サインインで即時更新を試せる |
| MDM管理 | クライアントが定期的に確認。VS Codeではポリシー同期コマンドで試験可能 |
| ファイルベース | ファイル更新後に対応クライアントを再起動 |
利用者が複数のCopilotライセンスを持つ場合は、個人設定の「Usage billed to」で、管理対象のエンタープライズが選択されているかも確認してください。別の課金元を使用していると、期待したエンタープライズ設定を受信しない可能性があります。(GitHub Docs)
サーバー管理だけに依存する場合の注意点
Fail Closedは、JSON不正や未解決変数など、取得した設定を安全に検証できない場合に機能します。
一方、サーバー管理設定の取得に失敗し、クライアントにキャッシュもない場合は、そのセッションでサーバー管理ポリシーを利用できないことがあります。GitHubは、サーバー応答がなくても制限を維持する必要がある場合、MDM管理またはファイルベースの設定を使うよう案内しています。(GitHub Docs)
すでに適用済みのポリシーがある状態で取得エラーが起きた場合は、以前のポリシーが保持され、取得エラーを理由に制限が緩くならないよう処理されます。(GitHub Docs)
常時適用が必要な端末では、次の構成を検討してください。
- サーバー管理で全社・チーム単位の許可リストを管理する
- MDM管理で最低限のデバイス制限を設定する
- Linuxや隔離環境ではファイルベース設定を併用する
- 複数層で共通して許可するサーバーを自動テストする
ただし、複数層を増やすほど設定の共通部分が狭くなります。ポリシー台帳を作成し、どの設定ソースがどのMCPサーバーを許可しているかを管理してください。
MCPサーバーがブロックされたときの確認ポイント
| 症状 | 主な原因 | 対応 |
|---|---|---|
| 追加したMCPサーバーがすべて動かない | 空の許可リスト、JSON不正、MCPポリシー無効 | JSON検証、allowedMcpServers、MCPポリシーを確認 |
| 特定のリモートサーバーだけ動かない | URLやパスの不一致、未解決変数 | 実際のURLとserverUrlを比較 |
| 特定のローカルサーバーだけ動かない | コマンド、引数、順序、ラッパーの不一致 | 実際のコマンド配列を取得して完全一致させる |
| 名前は許可されているのに動かない | serverNameだけに依存、別層でURL・コマンドが未許可 | serverUrlまたはserverCommandで定義 |
| 許可リストにも拒否リストにもある | 拒否が優先されている | 拒否リストを修正するか意図した動作か確認 |
| 一部の端末だけ動かない | MDM・ファイル設定の差、環境変数の差 | 端末ごとの有効ポリシーを比較 |
| 一部のチームだけ動かない | overridable、チームマッピング、複数チーム所属 | チーム設定ファイルとマッピングを確認 |
| 変更が反映されない | 更新待ち、古いクライアント、課金元の違い | 再起動、再サインイン、クライアント更新、課金元確認 |
| 空の許可リストなのにGitHub MCPが使える | 組み込みサーバーの適用除外 | 仕様どおりの動作 |
| VS Codeでは動くが別クライアントでは動かない | クライアントまたはプロパティの対応差 | 現在の対応クライアントとバージョンを確認 |
特に多いのは、serverCommandの見た目が同じでも、-y、cmd /c、絶対パス、パッケージのバージョン指定などが異なるケースです。
例えば、許可リストが次の設定だったとします。
{
"serverCommand": [
"npx",
"@playwright/mcp@latest"
]
}開発端末側が次のコマンドを使っていれば、一致しません。
npx -y @playwright/mcp@latest許可リストの確認では、コマンドを人間が読み比べるだけでなく、配列として比較することが重要です。
安全に運用するための判断基準
許可リストを基本にして拒否リストを補助的に使う
拒否リスト方式だけでは、今後登場する未知のMCPサーバーを止められません。
企業環境では、承認済みサーバーをallowedMcpServersへ登録し、危険な構成や緊急停止対象をdeniedMcpServersへ追加する設計が適しています。
サーバー名ではなくURLまたはコマンドを使う
serverNameはユーザーが変更できるため、正式な審査済みサーバーであることを保証できません。
- リモートMCPサーバーは
serverUrl - ローカルMCPサーバーは
serverCommand - URLやコマンドを持たない場合だけ
serverName
という基準で使い分けます。
ワイルドカードを必要最小限にする
次のような広い指定は避けます。
{
"serverUrl": "https://*.example.com/*"
}代わりに、管理対象のホストとパスを限定します。
{
"serverUrl": "https://mcp.example.com/approved/*"
}URL正規化によって表記上の回避は抑制されますが、広すぎるワイルドカード自体は管理者の設定どおりに許可されます。
ローカルパッケージはバージョン固定を検討する
serverCommandが確認するのはコマンド文字列と引数の一致です。
例えば、@latestを許可した場合、起動コマンドが同じでも将来取得されるパッケージ内容は変化する可能性があります。許可リストへの一致は、パッケージそのものの完全性や安全性を証明する仕組みではありません。
本番環境では、可能な範囲で次を実施します。
- 承認したバージョンを固定する
- 社内パッケージレジストリやミラーを使う
- ロックファイルやハッシュを確認する
- 更新時に再審査する
- 管理者が承認した配布経路だけを使う
MCP許可リストだけで安全対策を完結させない
MCP許可リストは「どのMCPサーバーを起動できるか」を制御する仕組みです。
許可したMCPサーバーがどのファイル、ネットワーク、認証情報、外部サービスへアクセスできるかは別途管理する必要があります。MCPサーバーは外部ツールやデータを提供するため、悪意のあるサーバーや設定不備のあるサーバーは機密情報の漏えいや有害な動作につながる可能性があります。(GitHub Docs)
Copilot CLIでは、エンタープライズ管理設定のサンドボックス機能により、ローカルMCPサーバーをサンドボックス内で実行させることもできます。
{
"sandbox": {
"enabled": true,
"sandboxMcpServers": true,
"allowBypass": false
}
}必要に応じて、ファイルシステム、ネットワーク、認証情報へのアクセスも制限します。(GitHub Docs)
JSON変更をPull Requestで管理する
設定ミスがFail Closedによる広範囲なブロックにつながるため、managed-settings.jsonを直接変更する運用は避けます。
次の管理方法が有効です。
- Pull Requestを必須にする
- JSON構文をCIで検証する
- MCP管理者とセキュリティ担当者のレビューを必須にする
- 許可理由と有効期限を記録する
- 動作確認済みの設定へすぐ戻せるようにする
- 定期的に未使用サーバーを削除する
許可リストの項目には、設定ファイル内のコメントではなく、Pull Requestや別のMCP台帳で申請者、利用目的、データ範囲、承認日を記録すると管理しやすくなります。
まず実施すべきこと
GitHub Copilot EnterpriseでMCPサーバーを安全に管理するには、最初に現在のURLと起動コマンドを棚卸しし、allowedMcpServersを使ったデフォルト拒否の方針を決めます。
その後、次の順序で導入してください。
- 「MCP servers in Copilot」ポリシーを確認する
- 既存のカスタムレジストリ制限との重複を解消する
- URLとローカルコマンドを許可リストへ登録する
- 緊急停止対象を拒否リストへ登録する
- JSONと環境変数を自動検証する
- 少人数で許可・拒否の両方をテストする
- サーバー管理、MDM、ファイル管理の全レイヤーを確認する
- 本番展開後も利用状況と設定変更を定期的に見直す
MCPサーバーがブロックされた場合は、単一の許可リストだけを見るのではなく、拒否ルール、すべての許可リスト、実際のURL・コマンド、Fail Closedの発生有無を順番に確認することが解決への近道です。
コメント