MCP-Server erweitern Copilot um externe Werkzeuge und Datenquellen. Bevor du als Entwickler einem einzelnen Server vertraust, lohnt sich eine Prüfung auf Code- und Tool-Ebene, dazu gibt es einen eigenen Artikel mit Prüfliste, siehe Abgrenzung unten. Dieser Artikel sitzt eine Ebene darüber: Wer in deiner Organisation oder deinem Enterprise überhaupt entscheidet, ob MCP genutzt werden darf, und warum diese Entscheidung standardmäßig gar nicht getroffen ist.
Die Policy heißt „MCP servers in Copilot“ und sitzt auf Organisationsebene
GitHub stellt für MCP in Copilot eine eigene Admin-Policy bereit, laut Dokumentation benannt als „MCP servers in Copilot“. Organisationen und Enterprises steuern darüber, ob ihre Mitglieder MCP-Server überhaupt verwenden dürfen. Die Policy wird zentral verwaltet, nicht von einzelnen Entwicklern.
Warum sie standardmäßig deaktiviert ist
Im Klartext: Ohne aktives Eingreifen eines Admins ist MCP in einer Organisation nicht freigeschaltet. Wortgleiches Zitat aus der Live-Doku:
„The policy is disabled by default.“
Das bedeutet, dass die Entscheidung für MCP nirgends automatisch fällt. Wer MCP in der eigenen Organisation nutzen will, muss die Policy aktiv setzen. Wer sie nicht kennt, nutzt Copilot ohne MCP, ohne dass das irgendwo als Einschränkung sichtbar wird.
Welche Lizenzstufen die Policy überhaupt erfasst
Das ist der Teil, der in der Praxis am häufigsten übersehen wird: Die Policy gilt nicht für jeden Copilot-Plan. Wortgleiches Zitat:
„The MCP policy only applies to users who have a Copilot Business or Copilot Enterprise subscription from an organization or enterprise that configures the policy.“
Und weiter, ebenfalls wortgleich:
„Copilot Free, Copilot Pro, Copilot Pro+, or Copilot Max do not have their MCP access governed by this policy.“
Für eine Organisation heißt das: Nur Business- und Enterprise-Lizenzen unterliegen der zentralen Steuerung. Individuallizenzen wie Pro, Pro+ oder Max fallen nicht unter diese Admin-Policy, dort entscheidet die Nutzung von MCP jeder Account für sich. Wenn in deinem Unternehmen beide Lizenzmodelle parallel existieren, etwa weil Einzelpersonen eigene Pro-Abos neben einer Business-Organisation nutzen, greift die zentrale Steuerung nur bei einem Teil der Accounts.
Lokale MCP-Server umgehen die Org-Policy ohnehin
Selbst wenn die Policy aktiv und auf eng gestellt ist, gilt das nur für den Teil der MCP-Nutzung, den die Organisation sieht und steuert. Die Doku unterscheidet an mehreren Stellen (unter anderem für VS Code, JetBrains, Xcode, Eclipse und Visual Studio) zwischen Remote- und lokalen Servern. Wortgleiches Zitat aus dem vollständigen Satz:
„Remote servers are hosted externally for easier setup and sharing, while local servers run on your local machine and can access local resources.“
Lokale Server laufen auf dem Rechner des Entwicklers und greifen von dort auf lokale Ressourcen zu, unabhängig davon, was die Org-Policy zu MCP insgesamt sagt. Eigene Einordnung, keine Doku-Aussage: Eine auf „aus“ gestellte oder gar nicht gesetzte Policy sagt damit wenig darüber, ob auf Entwicklerrechnern bereits lokale MCP-Server mit Zugriff auf lokale Dateien, Umgebungsvariablen oder Zugangsdaten laufen. Die Policy regelt die organisationsweite Freigabe, nicht automatisch jeden technischen Zugriffspfad.
Was das für Plattform-Teams praktisch bedeutet
Eigene Einordnung, keine Doku-Aussage: Für ein Plattform- oder Security-Team ergeben sich aus den drei Punkten oben drei getrennte Prüffragen, keine einzelne. Erstens, ist die Policy in der eigenen Organisation überhaupt gesetzt, oder läuft sie im unkonfigurierten Standardzustand. Zweitens, welche Lizenzstufen sind in der eigenen Organisation im Einsatz, und welcher Anteil davon fällt laut den Zitaten oben gar nicht unter die zentrale Steuerung. Drittens, welche lokalen MCP-Server existieren auf Entwicklerrechnern bereits, unabhängig vom Stand der Org-Policy. Eine Antwort auf Frage eins beantwortet weder Frage zwei noch Frage drei.
Abgrenzung zu zwei anderen Artikeln auf diesem Blog
Dieser Artikel behandelt bewusst nicht, wie ein einzelner Entwickler vor dem Einsatz prüft, ob er einem konkreten MCP-Server vertrauen kann, das ist die Nutzer-Ebene aus „MCP-Server prüfen: was du liest, bevor ein Agent ihm vertraut“.
Ebenso wird hier nicht erneut erklärt, wie Copilot-Lizenzstufen allgemein Zugriffsrechte und Seats definieren, das ist Thema von „GitHub-Copilot-Zugriff verwalten: Seats und Policies als Zugriffsrecht, nicht als Lizenzfrage“. Dieser Artikel hier setzt genau an der MCP-spezifischen Admin-Policy an, nicht an Lizenzmanagement im Allgemeinen.
Kurzcheck für den Einstieg
Vier Fragen, die sich mit den Zitaten oben direkt beantworten lassen, ohne weitere Recherche: Ist die Policy „MCP servers in Copilot“ in deiner Organisation gesetzt, oder läuft sie im deaktivierten Standardzustand. Welche Copilot-Pläne sind bei euch im Einsatz, und welche davon fallen laut Doku gar nicht unter diese Policy. Wisst ihr, welche lokalen MCP-Server auf Entwicklerrechnern bereits konfiguriert sind. Und, daran anschließend: Wer in eurer Organisation ist für die Antwort auf die ersten drei Fragen zuständig.
Fragen zur MCP-Governance in eurer Copilot-Organisation kannst du direkt an mm@mhm-dl.de schicken.
Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.
Kommentar verfassen