MCP-Konfigurationssicherheit bei Änderungen am Repository

Eine MCP-Konfiguration im Repository ist ausführbares Deployment-Material im Gewand einer kleinen JSON-Datei. Sie kann eine Binärdatei auswählen, ein Paket herunterladen, den Startort des Prozesses bestimmen, Daten übergeben und ihm Zugriff auf das Checkout-Verzeichnis geben. Deshalb ist die Sicherheit der MCP-Konfiguration zuerst ein Problem für den Pull-Request-Review, bevor sie zu einem Sicherheitsproblem des Agents wird.

Ich habe erlebt, dass Teams eine Stunde darüber diskutierten, ob ein Agent ein Tool aufrufen darf, und anschließend einen Launcher eincheckten, der an diesem Nachmittag beliebigen Code installieren konnte, auf den sich ein öffentlicher Paketname auflöst. Die Tool-Liste ist nur der sichtbare Teil. Der Prozess, der diese Tool-Liste erzeugt, hat bereits eine Grenze überschritten.

Die Konfiguration ist eine Anweisung zum Starten eines Prozesses

Eine Änderung an .mcp.json verdient dieselbe Aufmerksamkeit wie eine Änderung an einem Build-Skript, weil ein Client seine Felder in einen lokalen Prozess übersetzen muss. Das genaue Schema unterscheidet sich je nach Host, aber die Grundform ist vertraut: ein Befehl, ein Argument-Array, optionale Umgebungsvariablen und manchmal ein Arbeitsverzeichnis oder eine Transport-Einstellung.

Dieser Prozess startet mit den Berechtigungen des Entwicklers oder Agent-Hosts, der ihn ausführt. Er kann Dateien lesen, auf die dieser Benutzer Zugriff hat, Dateien an Orten anlegen, an denen der Benutzer schreiben darf, ausgewählte Umgebungswerte übernehmen und Netzwerkverbindungen herstellen, sofern das Betriebssystem oder eine andere Kontrolle dies nicht verhindert. Die spätere Rolle als «MCP-Server» schränkt diese normalen Prozessberechtigungen nicht ein.

Prüfer leiten Sicherheit oft aus dem Paketnamen oder aus der begrenzten Zahl der beworbenen Tools ab. Beides ist kein verlässlicher Hinweis. Ein Server namens issue-reader bietet nach dem Start vielleicht nur Leseoperationen an, während sein Launcher ein Shell-Wrapper-Skript aufruft, das ein Token aus dem Home-Verzeichnis liest. Ein Server mit weit gefasstem Namen kann dagegen eine eingecheckte Binärdatei sein, die genau das tut, was im Repository dokumentiert ist. Beginne mit Belegen, nicht mit Namen.

Die riskante Zeile wirkt oft völlig unscheinbar:

{
  "mcpServers": {
    "docs": {
      "command": "npx",
      "args": ["-y", "@example/docs-mcp"]
    }
  }
}

Das bedeutet nicht, dass npx oder ein Registry-Paket automatisch unzulässig sind. Es bedeutet, dass der Pull-Request einen Teil der ausführbaren Lieferkette auf einen späteren Zeitpunkt verlagert, und zwar auf jedem Rechner, der den Server startet. Der Prüfer muss wissen, welche Paketversion ausgeführt wird, woher sie kommt, was sie installiert und was beim ersten Start geschieht.

Eine eingecheckte Konfiguration erzeugt außerdem sozialen Druck. Sobald sie im Repository liegt, sieht ein neuer Beitragender einen Server, der als Teil der Projekteinstellungen beschrieben ist, und nimmt an, dass er bereits geprüft wurde. Genau deshalb braucht diese Dateiklasse einen Verantwortlichen und eine feste Review-Gewohnheit.

MCP-Nachrichten und Repository-Launcher sind verschiedene Ebenen

Die Spezifikation des Model Context Protocol beschreibt die Kommunikation zwischen MCP-Client und -Server, einschließlich Initialisierung, Tool-Erkennung, Tool-Aufrufen und Transportverhalten. Sie definiert kein einheitliches .mcp.json-Format und macht eine Client-Konfiguration nicht harmlos. Jeder Client entscheidet, wo er die Konfiguration liest und wie er einen lokalen stdio-Server startet.

Diese Unterscheidung klingt theoretisch, bis ein Review schiefgeht. Das Protokoll kann einen Server nach dem Verbindungsaufbau auf eine deklarierte Menge von Methoden beschränken. Die Host-Konfiguration entscheidet, welches Programm überhaupt die Möglichkeit erhält, diese Methoden anzukündigen. Wenn du nur das Verhalten auf Protokollebene prüfst, beginnt dein Review erst, nachdem der Launcher bereits gehandelt hat.

Halte zwei Fragen getrennt:

• Welche Aktionen kann der verbundene Server über seine Tools anfordern oder ausführen?
• Was tut der lokale Launcher, bevor der Client eine Serververbindung hat?

Die erste Frage gehört zu Agent-Berechtigungen, Genehmigungsabläufen und Tool-Design. Die zweite betrifft das Vertrauen in das Repository, die Prozessausführung, die Herkunft von Abhängigkeiten und den Umfang des Dateisystemzugriffs. Ein guter Review beantwortet beide Fragen, aber die Antwort auf eine darf niemals die Antwort auf die andere ersetzen.

Die Protokolldokumentation ermutigt Clients und Server, Fähigkeiten auszuhandeln. Das hilft bei der Kompatibilität, begründet aber kein Vertrauen in einen Repository-Befehl. Die Aushandlung kann dem Client mitteilen, dass ein Server Tools unterstützt. Sie kann nicht beweisen, dass Befehlspfad, Paketinhalt oder Start-Hook den Zugriff des Entwicklers verdienen.

Das erklärt auch, warum ein vertrauter Server in einer neuen Konfiguration trotzdem riskant sein kann. Der Server-Code kann unverändert sein, während ein geändertes Argument ihn auf einen anderen Endpunkt, eine andere Quelle für Anmeldedaten oder ein anderes Projektverzeichnis verweist. Der Startkontext ist Teil des Verhaltens.

Lies den gestarteten Befehl vor den beworbenen Tools

Prüfe die Befehlsauflösung als Kette, nicht als erste Zeichenfolge in der JSON-Datei. Frage, welches Programm der Host tatsächlich ausführt, nachdem er den Befehl über die aktuelle Umgebung aufgelöst hat. python, node, uvx, npx, bunx, sh und ein relativer Pfad bedeuten jeweils, dass ein weiterer Resolver die endgültige ausführbare Datei bestimmt.

Ein direkter absoluter Pfad ist am einfachsten zu prüfen, braucht aber ebenfalls eine nachvollziehbare Herkunft. Ein relativer Repository-Pfad kann vertretbar sein, wenn das Repository die Datei enthält und die normale Codeprüfung sie abdeckt. Ein bloßer Befehlsname erfordert eine Prüfung des PATH-Verhaltens auf dem Rechner des Entwicklers. Ein Shell-Befehl verdient besondere Skepsis, weil Anführungszeichen, Expansionen, Pipes, Umleitungen und Befehlsersetzung mehr Ausführung verbergen als ein einfaches Argument-Array.

Argumente verdienen einen eigenen Prüfdurchgang. Prüfer lesen häufig die ersten beiden Argumente, erkennen einen Paketnamen und gehen weiter. Lies jedes Element. Ein Argument kann eine Konfigurationsdatei außerhalb des Checkouts auswählen, ein Ausgabeverzeichnis bestimmen, einen Plugin-Loader aktivieren, auf eine alternative Registry zeigen oder aus einem harmlosen Befehl einen Skript-Interpreter machen.

Betrachte den Unterschied zwischen diesen beiden Einträgen:

{
  "command": "node",
  "args": ["tools/mcp-server.js", "--root", "."]
}

{
  "command": "node",
  "args": ["tools/mcp-server.js", "--config", "../../shared/runtime.json"]
}

Der zweite Eintrag kann legitim sein. Er schafft aber eine Abhängigkeit von einer Datei außerhalb der Checkout-Grenze, die der Pull-Request möglicherweise nicht zeigt. Wenn der Server aus dieser Datei Anweisungen oder Anmeldedaten liest, können Prüfer die Änderung nicht allein anhand des Diffs bewerten. Bitte den Autor, die referenzierte Konfiguration in den Review einzubeziehen, sie durch einen expliziten Repository-Pfad zu ersetzen oder zu erklären, warum die externe Datei erforderlich ist.

Akzeptiere keine vage Antwort wie «Das erledigt das Paket». Das Paket kann heute korrekt damit umgehen, aber die Änderung überträgt ihm trotzdem Autorität. Eine brauchbare Antwort nennt das Programm, seine Version, seine Eingaben und die erwarteten Dateien. Wenn der Autor den exakten Befehl nicht aus einem frischen Checkout ausgeführt hat, beschreibt er eine Absicht und kein tatsächliches Verhalten.

Für Shell-Wrapper sollte eine klare Grundregel gelten: Lehne sie ab, sofern das Repository keinen konkreten Bedarf hat, den ein Argument-Array nicht abbilden kann. Ein Wrapper wirkt praktisch, weil er eine Umgebungsvariable setzt und zwei Helfer startet. Gleichzeitig hängt der Review von Shell-Parsing-Regeln und allen Befehlen ab, die der Wrapper erreicht. Wenn er tatsächlich erforderlich ist, lege die Einrichtung in ein geprüftes Skript mit eindeutigem Dateinamen und prüfe dieses Skript wie Anwendungscode.

Paket-Runner machen den Start zu einem Ereignis der Lieferkette

Ein Paket-Runner kann beim ersten Start des Servers Code herunterladen und ausführen. Deshalb ist ein Paketname allein keine vollständige Prüfung der Abhängigkeit. Genau deshalb verdienen npx -y package, uvx package und ähnliche Formen mehr Aufmerksamkeit als ein Befehl, der eine eingecheckte Datei aufruft.

Das häufigste Argument für einen nicht festgelegten Runner ist Bequemlichkeit. Beitragende müssen nichts manuell installieren, und das Projekt wirkt aktuell. Der Preis ist, dass das Repository nicht mehr den genauen Code angibt, den es jeden Beitragenden ausführen lässt. Eine neu veröffentlichte Paketversion, eine geänderte Abhängigkeit oder eine Änderung der Registry-Zuordnung kann das Verhalten ohne neuen Pull-Request verändern.

Lege mindestens die Version fest und mache die Quelle nachvollziehbar:

{
  "mcpServers": {
    "schema-checker": {
      "command": "npx",
      "args": ["-y", "@acme/[email protected]"],
      "cwd": "${workspaceFolder}"
    }
  }
}

Das Festlegen der Version zertifiziert das Paket nicht. Es macht das Prüfziel stabil. Ein Prüfer kann diese Version untersuchen, sie mit der vorherigen vergleichen und für ein Update einen bewussten Pull-Request verlangen. Nutze die Lock-Datei des Paketmanagers, Integritätsdaten oder ein eingechecktes Artefakt, sofern die umgebende Toolchain dies unterstützt. Eine Versionszeichenfolge ohne Möglichkeit, den heruntergeladenen Inhalt zu verifizieren, lässt eine Lücke, ist aber immer noch besser als ein unbeschränkter Name.

Verwechsle den Cache eines Paketmanagers nicht mit einem Review. Ein Cache verändert nur, woher die Bytes auf einem Rechner stammen. Er sagt dem Prüfer nicht, welche Bytes andere Beitragende erhalten, ob Installations-Hooks ausgeführt werden oder ob sich ein sauberer Rechner genauso verhält.

Stelle eine unangenehme Frage, die viele schwache Änderungen aufdeckt: Was passiert, wenn das Paket fehlt? Wenn die Antwort lautet «Es installiert sich selbst», enthält die Konfiguration einen Netzwerk- und Codeausführungspfad. Wenn die Antwort lautet «Der Start schlägt fehl und weist auf eine dokumentierte Abhängigkeit hin», hat sich das Team für einen langsameren, aber sichtbareren Einrichtungsweg entschieden. Keine der beiden Antworten ist automatisch richtig. Den Unterschied zu verschweigen, ist falsch.

Arbeitsverzeichnisse und Umgebungsvariablen legen den tatsächlichen Umfang fest

Das Feld cwd gibt an, wo ein Prozess nach relativen Dateien zu suchen beginnt. Diese Wahl steuert oft mehr, als viele erwarten. Zahlreiche Tools suchen Projektkonfigurationen, Sprachlaufzeiten, Ignore-Dateien, Anmeldedaten und Plugins, indem sie vom Arbeitsverzeichnis aus nach oben gehen. Ein Server, der im Repository-Stamm beginnt, sieht eine andere Umgebung als ein Server, der in einem eigenen Fixture-Verzeichnis startet.

Lege das Arbeitsverzeichnis bewusst fest. Wenn ein Server nur generierte API-Spezifikationen unter tools/specs benötigt, starte ihn nicht in einem übergeordneten Verzeichnis, das Deployment-Material und private Entwicklungsnotizen enthält. Wenn er das gesamte Checkout untersuchen muss, sollte das im Pull-Request stehen. Das Ziel ist nicht, jeden Pfad möglichst klein zu machen. Die Zugriffsmöglichkeiten, die der Prüfer genehmigt, sollen zu denen passen, die der Server tatsächlich erhält.

Umgebungsvariablen haben ein ähnliches Gewicht. Manche sind harmlose Betriebseinstellungen wie Sprache oder Port. Andere wählen eine Paket-Registry aus, erweitern einen Modulsuchpfad, aktivieren einen Debug-Modus, der Request-Inhalte schreibt, oder enthalten Anmeldedaten. Eine Konfiguration mit ${TOKEN} verbirgt den Token-Wert in der Datei, übergibt dieses Geheimnis aber trotzdem an einen untergeordneten Prozess.

Vermeide Anmeldedaten in Repository-MCP-Konfigurationen, wenn der Server über eine separate Aktionsgrenze arbeiten kann. Wenn ein Server tatsächlich ein Geheimnis benötigt, dokumentiere die Quelle, den Zweck und die Frage, ob der Prozess es an untergeordnete Prozesse weitergeben kann. Schreibe keinen beispielhaften Produktions-Token in einen Kommentar oder ein kopiertes Shell-Protokoll. Entwickler kopieren das Beispiel, das am einfachsten funktioniert.

Auch übernommene Umgebungswerte verdienen Aufmerksamkeit. Ein Prozess kann weit mehr übernehmen, als die JSON-Datei auflistet. Der Host entscheidet, was er weitergibt, aber der Autor des Repositorys kann einen Befehl auswählen, der auf übliche Laufzeitorte zugreift. Das ist ein weiterer Grund, direkte, kleine Launcher allgemeinen Shells und Paket-Runnern vorzuziehen.

Ein Pull-Request-Diff kann den Ausführungsgraphen sichtbar machen

Die meisten Konfigurationsänderungen lassen sich prüfen, ohne nicht vertrauenswürdigen Code auszuführen. Erweitere den Diff zu den Prozessen und Eingaben, die er impliziert. Beginne mit einem fokussierten Diff statt mit der gerenderten Dateiansicht, damit entfernte Argumente und geänderte Pfade sichtbar bleiben:

git diff --check
git diff -- .mcp.json

Der erste Befehl meldet gefundene Leerzeichenfehler. Der zweite sollte jede hinzugefügte, entfernte und veränderte Zeile im Konfigurationspfad zeigen. Wenn das Repository die Datei an anderer Stelle speichert oder erzeugt, passe den Pfad an und bitte auch um die Änderung am Generator. Eine generierte Konfiguration ohne ihre Quelle ist ein unvollständiger Review.

Betrachte diese kleine Änderung:

 "mcpServers": {
   "release-notes": {
-    "command": "node",
-    "args": ["tools/release-notes-server.js"],
-    "cwd": "${workspaceFolder}"
+    "command": "npx",
+    "args": ["-y", "release-notes-mcp"],
+    "cwd": ".."
   }
 }

Die sichtbare Geschichte lautet: Das Team hat einen lokalen Helfer durch einen veröffentlichten Server ersetzt. Der Ausführungsgraph zeigt mehr. Der Client löst npx über den PATH des Entwicklers auf. npx kann release-notes-mcp und seine Abhängigkeiten herunterladen. Das Paket startet außerhalb des Repository-Stamms, weil cwd jetzt auf das übergeordnete Verzeichnis zeigt. Der Server kann dort Konfigurationen finden, Cache-Dateien schreiben oder benachbarte Projekte lesen. Für jeden dieser Schritte braucht es vor dem Merge eine Antwort.

Ein disziplinierter Review stellt in dieser Reihenfolge Belege zusammen:

1. Ermittle die endgültige ausführbare Datei und das genaue Paket oder die Repository-Datei, aus der sie stammt.
2. Liste jeden Dateipfad, jede URL, jede Registry und jeden Umgebungswert auf, der das Startverhalten verändern kann.
3. Beschreibe das Arbeitsverzeichnis des Prozesses und die Verzeichnisse, die der Server im Normalbetrieb liest oder beschreibt.
4. Bestätige, was auf einem sauberen Rechner geschieht, bevor ein Paket-Cache existiert.
5. Vergleiche den behaupteten Zweck des Tools mit den Berechtigungen, die der Launcher tatsächlich benötigt.

Diese Reihenfolge ist ein konkretes Arbeitsergebnis und keine Formalität. Sie verhindert den typischen Fehler, dass ein Prüfer eine Tool-Beschreibung genehmigt, während ein Installer, ein Laufzeit-Selektor oder ein übergeordnetes Verzeichnis in einer einzeiligen Änderung unbemerkt durchrutscht.

Wenn du eine Konfiguration zur Validierung ausführen musst, verwende ein Wegwerf-Konto oder eine isolierte Umgebung ohne Produktionsanmeldedaten und mit leerem Paket-Cache. Zeichne die aufgelöste ausführbare Datei, die Paketversion, ausgehende Hosts und geschriebene Dateien auf. Ein Screenshot der erfolgreichen Tool-Erkennung ist ein schwacher Beleg, weil er den Teil auslässt, der das größte Risiko verursacht hat.

Tool-Beschreibungen können einen weitreichenden Launcher nicht ausgleichen

Ein enges Tool-Schema macht die Vorgänge vor dem MCP-Handshake nicht ungeschehen. Teams behandeln die Ausgabe von tools/list häufig als Berechtigungsinventar und halten einen Server für sicher, weil er search_docs und read_status anbietet. Dieses Inventar beschreibt die Schnittstelle nach der Initialisierung. Über Paketinstallation, Konfigurationssuche, Telemetrie, untergeordnete Prozesse oder beim Start gelesene Dateien sagt es wenig aus.

Die Unterscheidung wirkt in beide Richtungen. Ein Server mit einem schreibenden Tool kann akzeptabel sein, wenn der Launcher festgelegt, lokal, dokumentiert und auf das vorgesehene Projekt beschränkt ist. Ein Server mit ausschließlich lesenden Tools kann unzulässig sein, wenn eine Repository-Konfiguration stillschweigend ein veränderliches Paket aus dem Netzwerk mit Zugriff auf den größeren Arbeitsbereich eines Entwicklers startet.

Bitte den Autor, den Lebenszyklus in einfachen Worten zu beschreiben: Was startet, was wird vor der Verbindung gelesen, was wird gegebenenfalls heruntergeladen und worauf kann der Server nach der Verbindung zugreifen? Diese Beschreibung sollte in einen Pull-Request passen. Wenn eine lange Untersuchung nötig ist, um sie zu beantworten, ist die Konfiguration für einen routinemäßigen Review zu indirekt.

Lass die Diskussion nicht mit «Wir vertrauen diesem Anbieter» enden. Vertrauen ist relevant, legt aber keine Version fest, schränkt kein Arbeitsverzeichnis ein und zeigt nicht, ob der Befehl eine alternative Registry verwendet. Das sind eigenständige Kontrollen mit unterschiedlichen Fehlerbildern.

Die Verantwortung des Repositorys braucht eine Absicherung zur Laufzeit

Der Repository-Review verhindert, dass unsichere Startanweisungen zu normalen Projekteinstellungen werden. Laufzeitkontrollen bleiben wichtig, weil eine genehmigte Konfiguration durch eine kompromittierte Abhängigkeit, einen bösartigen Prompt oder einen Benutzer missbraucht werden kann, der einen Agenten zu weitreichenden Aktionen auffordert.

Halte die Grenze klar. Das Repository kontrolliert, was es zum Start vorschlägt. Der Mensch am Rechner kontrolliert, ob eine bestimmte Agent-Sitzung handeln darf. Für sensible Aktionen braucht es Aufzeichnungen, mit denen der Bediener nachvollziehen kann, was der Agent getan hat, und die Sitzung abbrechen kann, wenn etwas schiefläuft.

Sallyport hält API- und SSH-Anmeldedaten aus dem Agent-Prozess heraus. Die Sitzungsautorisierung und das Aktivitätsprotokoll geben dem Bediener einen separaten Ort, um Aktionen zu genehmigen und zu prüfen. Das macht einen riskanten Repository-Befehl nicht harmlos. Deshalb steht die Konfigurationsprüfung weiterhin an erster Stelle.

Für Teams, die eine andere Grenze nutzen, gilt derselbe Test. Kann ein Entwickler sehen, welcher Agent-Prozess Zugriff angefordert hat? Kann er diesen Prozess stoppen, ohne unabhängige Arbeit zu beenden? Kann er einen versuchten von einem erfolgreichen Vorgang unterscheiden? Wenn die Antwort nein lautet, hat eine fehlerhafte Konfiguration nach dem Merge mehr Zeit, Schaden anzurichten.

Behandle diese Dateien als verantworteten Ausführungscode

Ein Repository sollte Code-Owner oder eine gleichwertige Review-Regel für MCP-Konfigurationen, ihre Wrapper-Skripte und alle Paketmanifeste festlegen, die bestimmen, was der Launcher installiert. Der Verantwortliche muss kein Sicherheitsspezialist sein. Er braucht genug Kontext, um zu fragen, warum diese Änderung dieses Programm mit diesen Zugriffsmöglichkeiten startet.

Halte Konfigurationen klein. Ein Server pro Zweck lässt sich leichter prüfen als ein universeller Helfer, der jedes System erreicht, das ein Entwickler verwendet. Beschreibe ungewöhnliche Anforderungen neben der Konfiguration in normaler Prosa: erwarteter Befehl, Richtlinie für Paketversionen, Arbeitsverzeichnis, erforderlicher Netzwerkzugriff und vorgesehene Eingaben. So wird aus implizitem Teamwissen etwas, das der nächste Prüfer hinterfragen kann.

Der praktische Test ist einfach. Gib den Diff einem erfahrenen Entwickler, der das Feature nicht kennt, und bitte ihn zu erklären, was auf einem sauberen Rechner ausgeführt wird, wo es ausgeführt wird und was es sehen kann. Wenn er diese Fragen nicht anhand des Pull-Requests und des referenzierten Codes beantworten kann, braucht die Änderung weitere Arbeit, bevor sie ins Repository aufgenommen wird.