GitHub gibt Copilot eine zentrale MCP-Schranke

GitHub hat am 6. August 2026 zentrale Allow- und Denylisten für Model Context Protocol (MCP)-Server in den Enterprise-Einstellungen von Copilot veröffentlicht. Nach Angaben von GitHub ist die Funktion allgemein verfügbar und legt fest, welche Server Copilot-Clients ausführen dürfen.¹

Damit wandert eine Sicherheitsentscheidung aus der einzelnen Entwicklerumgebung in die Plattform-Policy. Das zählt, sobald ein MCP-Server Werkzeuge, zusätzlichen Kontext oder lokale Befehle in die Entwicklungsumgebung bringen kann.

Eine Regel für mehrere Copilot-Clients

GitHub führt dafür die Schlüssel allowedMcpServers und deniedMcpServers in den verwalteten Einstellungen ein.¹ Remote-Server lassen sich über ihre URL erfassen, lokale Server über Befehl und Argumente sowie Server über ihren Namen. GitHub nennt als durchsetzende Clients derzeit die Copilot-App, die Copilot-CLI und VS Code.¹

Ein Servername reicht als Sicherheitsmerkmal nicht aus. Er kann geändert werden. Für eine Freigabe zählen daher das präzise Remote-Ziel oder ein klar abgegrenzter lokaler Befehl mit seinen Argumenten.

Fehlkonfigurationen müssen blockieren

Eine fehlerhafte oder nicht verifizierbare Regel muss den betroffenen Server blockieren. GitHub beschreibt dieses geschlossene Fehlerverhalten ausdrücklich.¹ Treffen Regeln aus mehreren Policy-Ebenen zusammen, muss ein Server jede Ebene passieren.

Das verhindert, dass eine unklare Konfiguration Zugriff erweitert. Gerade lokale MCP-Server verdienen Aufmerksamkeit: Ein erlaubter Befehl ist keine abstrakte Kennung. Er kann auf dem Rechner eines Entwicklers ausgeführt werden.

GitHub erlaubt in serververwalteten Umgebungen außerdem überschreibbare Listen.¹ Ein zentraler Mindeststandard kann damit bestehen bleiben, während einzelne Bereiche ergänzende Einschränkungen oder eng begrenzte Ausnahmen benötigen. Solche Ausnahmen gehören sichtbar in die Policy. Eine lokale Sonderlösung ist später schwerer zu prüfen und zu widerrufen.

Der Test vor dem breiten Rollout

Der Rollout sollte mit wenigen echten Entwicklungsabläufen beginnen. Dafür braucht es drei klare Erwartungen:

1. Ein erlaubter Server funktioniert in jedem vorgesehenen Copilot-Client.
2. Eine absichtlich fehlerhafte Regel blockiert den Server.
3. Ein Konflikt zwischen Policy-Ebenen erzeugt kein stilles Durchrutschen.

Die Ergebnisse sollten protokolliert werden. Besondere Aufmerksamkeit verdienen lokale Befehle und ihre Argumente, denn zu breite URL-Muster und vergessene Freigaben werden sonst selbst zum Risiko.

Eine gepflegte MCP-Liste ist kein Papierkorb für alle denkbaren Integrationen. Sie ist eine Sicherheitsgrenze. Plattformteams sollten diese Grenze testen, verstehen und kontrolliert ändern können. Erst dann schafft die zentrale Copilot-Policy im Alltag tatsächlich Orientierung.

Footnotes

1. https://github.blog/changelog/2026-08-06-mcp-allowlists-in-enterprise-managed-settings ↩ ↩² ↩³ ↩⁴ ↩⁵