GitHub MCP sicher einrichten

Der offizielle GitHub MCP Server kann Quellcode lesen und – abhängig von den freigegebenen Werkzeugen – Repositories, Issues und Pull Requests verändern. Beginne deshalb mit der kleinsten nötigen Berechtigung.

GitHub MCP als Remote-Server einrichten

Hinterlege in einem Remote-MCP-fähigen Client diese URL:

https://api.githubcopilot.com/mcp/

Wenn der Client GitHubs OAuth-Flow unterstützt, ist kein selbst erstelltes Token nötig. Andernfalls kann ein Fine-grained Personal Access Token als Bearer-Token verwendet werden. Seine Repository-Auswahl und Rechte sollten exakt auf die Aufgabe begrenzt sein.

GitHub MCP lokal einrichten

docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server

Übergib das Token über die geschützte Umgebungsverwaltung des Clients und nie als Klartext in einer eingecheckten Konfigurationsdatei. Lokal ist alternativ eine browserbasierte OAuth-Anmeldung möglich.

Funktionsumfang von GitHub MCP begrenzen

Starte nach Möglichkeit im Read-only-Modus und aktiviere nur benötigte Toolsets. Der Lockdown-Modus begrenzt Zugriffe zusätzlich auf Repositories, an denen der angemeldete Benutzer mitarbeitet. Schreibrechte sollten erst nach einem Testlauf und mit menschlicher Bestätigung aktiviert werden.

Einrichtung prüfen

Teste zunächst get_me und einen reinen Lesezugriff auf ein ausgewähltes Repository. Kontrolliere anschließend in GitHub die Token- beziehungsweise OAuth-Berechtigungen und widerrufe nicht mehr benötigte Zugänge.

Toolsets gezielt auswählen

Der GitHub MCP Server organisiert seine Funktionen in Themengruppen wie Repositories, Issues, Pull Requests, Actions und Code Security. Statt alle Gruppen zu aktivieren, sollten nur die für die geplante Aufgabe tatsächlich benötigten eingeschaltet werden – wer nur Issues durchsuchen will, braucht keinen Zugriff auf Actions-Workflows oder Code-Security-Meldungen. Eine kleinere Toolset-Auswahl reduziert nicht nur das Sicherheitsrisiko, sondern auch die Anzahl der Werkzeugdefinitionen im Kontext des Sprachmodells.

Unterschiede zwischen OAuth und Personal Access Token

OAuth ist für interaktive Nutzung meist die bequemere Wahl, weil kein Token manuell erzeugt und verwaltet werden muss; das Token bleibt laut Dokumentation nur im Arbeitsspeicher. Für nicht-interaktive Automatisierung, etwa in einer CI/CD-Pipeline, ist ein Fine-grained Personal Access Token oder eine GitHub-App-Anmeldung praktikabler, weil dort kein Browserfenster geöffnet werden kann. In beiden Fällen gilt: Je enger die Rechte, desto geringer der Schaden bei einem kompromittierten Client.

Vorgehen bei Verdacht auf Missbrauch

Zeigt das Audit-Log ungewöhnliche Aktivität, etwa Commits oder Pull-Request-Kommentare zu ungewöhnlichen Zeiten, sollte das betroffene Token oder die OAuth-Autorisierung sofort widerrufen und durch ein neues, enger begrenztes ersetzt werden. Anschließend empfiehlt sich eine Durchsicht der zuletzt vom Agenten ausgeführten Aktionen, um mögliche unautorisierte Änderungen zu identifizieren und rückgängig zu machen.

Quelle: offizielles Repository github/github-mcp-server, geprüft am 03.09.2026.