GitHub Copilot: MCP-Sicherheit wird zur Fail-Closed-Policy

GitHub Copilot kann MCP-Server in Enterprise-Umgebungen jetzt zentral erlauben oder sperren – und behandelt fehlerhafte oder nicht verifizierbare Richtlinien bewusst als Blockade. Damit wird aus der lokalen Tool-Konfiguration ein Endpoint-Policy-Thema.

Die am 6. August veröffentlichte Funktion ergänzt die Enterprise Managed Settings um allowedMcpServers und deniedMcpServers. Sie ist laut GitHub allgemein verfügbar und wird in der GitHub Copilot App, der Copilot CLI und VS Code durchgesetzt.

Worum es operativ geht

MCP verbindet Coding-Agenten mit lokalen und Remote-Tools. Genau dort entsteht eine unangenehme Lücke: Ein Modell kann zwar nach den richtigen Berechtigungen fragen, aber der Toolserver selbst muss ebenso vertrauenswürdig, adressierbar und zentral kontrollierbar sein. GitHub verschiebt diese Entscheidung nun vom individuellen Client in eine verwaltete Policy.

Admins können Server anhand von drei Merkmalen matchen:

• serverUrl für Remote-Server über HTTP oder SSE, einschließlich Wildcards; GitHub kanonisiert URLs ausdrücklich gegen Umgehungsversuche.
• serverCommand für lokale stdio-Server – mit exaktem Kommando und Argumenten.
• serverName als Label. GitHub weist selbst darauf hin, dass dies nur Komfort ist: Nutzer können Namen ändern, also ist das kein Sicherheitsanker.

Der entscheidende Satz: fail closed

Eine kaputte oder nicht überprüfbare Konfiguration führt nicht zu einem permissiven Fallback. Sie blockiert. Treffen mehrere Richtlinienebenen zusammen, muss ein MCP-Server jede davon bestehen. Das ist die richtige Default-Logik für Agenten, die über Tools auf Code, Tickets, Cloud-APIs oder lokale Prozesse zugreifen können.

{
  "allowedMcpServers": [
    { "serverUrl": "https://mcp.intern.example/*" },
    { "serverCommand": "npx", "args": ["-y", "@team/mcp-server"] }
  ],
  "deniedMcpServers": [
    { "serverUrl": "https://*.untrusted.example/*" }
  ]
}

Beispiel zur Illustration der dokumentierten Matcher-Arten; keine produktionsfertige Policy.

Was Teams jetzt prüfen sollten

1. Tool-Inventar erstellen: Welche MCP-Server laufen heute remote, welche über lokale Commands?
2. URLs als Sicherheitsgrenze behandeln: Wildcards klein halten und kanonische Zieladressen definieren.
3. Stufen testen: Da mehrere Policy-Layer kumulativ wirken, gehören Konflikttests in den Rollout.
4. Labels nicht überbewerten: Für Durchsetzung URL oder Command nutzen, nicht den frei wählbaren Servernamen.

Das ist kein neuer MCP-Transport und keine neue Agentenfähigkeit. Es ist wichtiger: GitHub macht die Tool-Auswahl in Copilot zu einer durchsetzbaren Enterprise-Policy. Mit dem weiteren Einzug von MCP in Entwicklerarbeitsplätze wird genau diese unspektakuläre Kontrollschicht zum Sicherheitsfundament.

Quelle: GitHub Changelog: MCP allowlists in enterprise managed settings (6. August 2026; von GitHub am 7. August UTC veröffentlicht/aktualisiert).