GitHub hat im Changelog vom 6. August 2026 eine neue Kontrollmöglichkeit für Unternehmen vorgestellt: Enterprise Owners können zentral festlegen, welche Model-Context-Protocol-Server GitHub-Copilot-Clients verwenden dürfen. Dafür stehen in den Enterprise Managed Settings die Schlüssel allowedMcpServers und deniedMcpServers bereit. Die Funktion ist laut GitHub allgemein verfügbar.
Für Unternehmen ist das mehr als eine zusätzliche Konfigurationsoption. MCP-Server verbinden KI-Assistenten mit Werkzeugen und Datenquellen. Ohne zentrale Regeln kann sich die tatsächlich nutzbare Integrationslandschaft schneller verändern als klassische Softwarefreigaben. Eine Allowlist schafft deshalb eine technische Durchsetzungsebene – ersetzt aber weder die Prüfung des Servers noch klare Verantwortlichkeiten für Daten, Berechtigungen und Änderungen.
Was GitHubs MCP-Allowlists technisch abdecken
Bestätigt ist: Die Regeln werden in copilot/managed-settings.json im .github-private-Repository der Quellorganisation hinterlegt und auf dem Standard-Branch eingecheckt. Unternehmen können Server über eine entfernte URL, einen lokalen Befehl oder einen vergebenen Namen identifizieren. GitHub nennt dafür die Matcher serverUrl, serverCommand und serverName.
Bei entfernten HTTP- oder SSE-Servern unterstützt serverUrl Platzhalter und normalisiert URLs, damit abweichende Schreibweisen die Regel nicht einfach umgehen. Lokale stdio-Server lassen sich über serverCommand anhand des exakten Befehls und seiner Argumente abgleichen. serverName ist laut GitHub nur eine Komfortfunktion und kein belastbares Sicherheitsmerkmal, weil Nutzer einen Server umbenennen können.
Die Richtlinien arbeiten nach dem Fail-closed-Prinzip: Eine fehlerhafte oder nicht verifizierbare Konfiguration wird blockiert. Treffen Regeln aus mehreren Ebenen zusammen, muss ein Server jede Ebene bestehen. In serververwalteten Installationen können die Schlüssel als overridable markiert werden, sodass Teams auf einer zentralen Basis zusätzliche eigene Erlaubnis- und Sperrlisten definieren können.
Zum Zeitpunkt der Ankündigung wird die Durchsetzung für die GitHub-Copilot-App, Copilot CLI und Visual Studio Code genannt. Daraus folgt nicht automatisch, dass jeder andere Client dieselben Regeln anwendet. Unternehmen sollten daher ihr reales Client-Inventar prüfen und nicht allein aus einer zentralen Datei auf eine lückenlose Abdeckung schließen.
Welcher Matcher für welchen Fall geeignet ist
- serverUrl für zentral betriebene Remote-Server verwenden, deren Endpunkte und Betreiber eindeutig feststehen.
- serverCommand für lokale Server einsetzen, wenn Befehl und Argumente kontrolliert verteilt und Änderungen nachvollzogen werden.
- serverName nur zur Lesbarkeit ergänzen, niemals als alleinige Sicherheitsentscheidung verwenden.
- deniedMcpServers für bekannte, unerwünschte oder vorübergehend gesperrte Verbindungen nutzen.
- allowedMcpServers als positive Grundauswahl führen, wenn nur geprüfte Integrationen zulässig sein sollen.
Die GNS-Einordnung: Für sensible Unternehmensumgebungen ist eine positive Auswahl in der Regel leichter zu prüfen als eine ausschließlich negative Liste. Eine Denylist muss jede unerwünschte Variante kennen; eine Allowlist begrenzt die Nutzung auf bereits bewertete Ziele. Ob dieses Modell für alle Teams passt, hängt jedoch von Entwicklungsfreiheit, Schutzbedarf und der Geschwindigkeit des Freigabeprozesses ab.
Freigabecheckliste für einen MCP-Server
- Geschäftlichen Zweck, verantwortliches Team und benötigte Copilot-Clients dokumentieren.
- Betreiber, Hosting, Datenflüsse und verarbeitete Datenklassen prüfen.
- Benötigte Werkzeuge und Berechtigungen auf das notwendige Minimum begrenzen.
- Bei Remote-Servern kanonische URL und zulässige Endpunkte festlegen; breite Platzhalter vermeiden.
- Bei lokalen Servern Befehl, Argumente, Paketquelle und Updateweg kontrollieren.
- Technische Eigentümer, fachliche Freigabe und Security-Review eindeutig zuordnen.
- Ablaufdatum oder regelmäßige Rezertifizierung sowie einen schnellen Sperrweg definieren.
- Erwartete Protokolle, Monitoring und Behandlung sicherheitsrelevanter Ereignisse festlegen.
Diese Prüfpunkte sind betriebliche Empfehlungen, keine von GitHub veröffentlichte Pflichtliste. Sie schließen die Lücke zwischen einem syntaktisch erlaubten Server und einer organisatorisch verantwortbaren Integration. Besonders wichtig ist die Rezertifizierung: Ein unveränderter Name oder Endpunkt bedeutet nicht, dass Implementierung, Betreiber, Berechtigungen oder Datenverarbeitung unverändert geblieben sind.
Ein gestufter Rollout statt einer Big-Bang-Sperre
Im ersten Schritt sollte das Unternehmen vorhandene MCP-Verbindungen und tatsächlich verwendete Clients inventarisieren. Dabei werden unbekannte Server nicht automatisch als legitim behandelt, nur weil sie bereits genutzt werden. Im zweiten Schritt entsteht eine kleine zentrale Baseline aus geprüften Integrationen. Plattform- und Security-Team testen anschließend, ob erlaubte Verbindungen funktionieren und nicht erlaubte Varianten tatsächlich blockiert werden.
Im dritten Schritt erhalten ausgewählte Teams die Richtlinie. Wenn lokale Ergänzungen geschäftlich nötig sind, können die von GitHub beschriebenen überschreibbaren Ebenen genutzt werden. Das sollte aber nicht zu einer verdeckten Aufweichung führen: Jede Team-Ausnahme braucht einen Eigentümer, einen dokumentierten Grund und ein Ablaufdatum. Im vierten Schritt folgt die breitere Einführung mit Supportweg, Änderungsprozess und messbaren Betriebszielen.
Geeignete Messgrößen sind die Zahl freigegebener Server, offene Prüfanträge, abgelehnte oder blockierte Verbindungsversuche, Zeit bis zur Entscheidung und überfällige Rezertifizierungen. Diese Kennzahlen bewerten nicht die Modellqualität. Sie zeigen, ob die Governance arbeitsfähig ist oder ob lange Freigabezeiten Teams dazu verleiten, nicht unterstützte Wege zu suchen.
Grenzen und offene Fragen vor dem produktiven Einsatz
Die Primärquelle beschreibt Matcher, Durchsetzungslogik, unterstützte Clients und den Einstieg in die Konfiguration. Sie liefert keine Aussage über die Sicherheit einzelner MCP-Server, keine Garantie für die inhaltliche Richtigkeit von Copilot-Ergebnissen und keine vollständige Bewertung unternehmensspezifischer Datenschutz- oder Compliance-Anforderungen. Auch Client-Versionen und spätere Erweiterungen müssen anhand aktueller GitHub-Dokumentation geprüft werden.
Die Funktion ist damit ein sinnvoller Kontrollpunkt, aber kein vollständiges Sicherheitsprogramm. Der größte Nutzen entsteht, wenn technische Richtlinie und organisatorischer Prozess dieselbe Entscheidung abbilden: Nur bekannte Server, mit nachvollziehbarem Zweck, begrenzten Berechtigungen, verantwortlichem Eigentümer und einem funktionierenden Widerrufsweg.