Wie prüft man MCP-Sicherheit im Pull Request?

Wie kommt ein MCP-Server ins Repository?

Dieser Beitrag schaut sich die Konfiguration an, die ein Pull Request für den Coding-Agenten mitbringt. Im Beitrag über Hooks ging es um die Befehle, die der Agent an bestimmten Stellen von sich aus ausführt, im Beitrag über das Review von KI-generiertem Code um den Code, den der Agent schreibt. Hier geht es um die Datei, die dem Agenten ein neues Werkzeug gibt.

MCP (Model Context Protocol) ist, wie die Spezifikation selbst es definiert, ein offenes Protokoll, das KI-Anwendungen mit externen Datenquellen und Werkzeugen verbindet. Auf der einen Seite steht der Agent, auf der anderen ein MCP-Server. Der Server definiert die Werkzeuge (Tools), die das Modell aufrufen kann: ein Issue lesen, einen Browser öffnen, eine Datenbank abfragen. Stand 18. Oktober 2026 ist die neueste Fassung der Spezifikation auf den 2026-07-28 datiert.

Meist ist der Server ein Programm, das auf Ihrem eigenen Rechner läuft. Das Coding-Tool startet es über die Zeilen command und args der Konfigurationsdatei und spricht mit ihm über die Standardeingabe und -ausgabe des Programms; die Spezifikation nennt das stdio. Bei einem entfernten Server steht in der Datei statt eines Befehls eine Adresse (url). Die Datei wird mit dem Code committet: Die Dokumentation von Claude Code empfiehlt, .mcp.json in die Versionsverwaltung aufzunehmen, damit alle im Team dieselben Werkzeuge nutzen. Jedes Tool liest dafür eine andere Datei:

Quelle: die MCP-Dokumentation des jeweiligen Tools, 18. Oktober 2026. Copilot CLI liest die Datei .vscode/mcp.json von VS Code nicht. In Antigravity CLI heißt die Datei im Repository .agents/mcp_config.json.

Die MCP-Spezifikation sagt in einem Satz, was das bedeutet: “Tools represent arbitrary code execution and must be treated with appropriate caution.” Der Sicherheitsleitfaden der Spezifikation verlangt außerdem von Clients, die Nutzer zu warnen, dass MCP-Server mit denselben Rechten laufen wie der Client. Eine Zeile in .mcp.json ist also der Name eines Programms, das auf den Rechnern aller im Team mit deren Rechten laufen wird.

Was ist Tool Poisoning?

Wann und wie das Modell ein Werkzeug aufruft, entscheidet es anhand von Name und Beschreibung des Werkzeugs. Invariant Labs hat in einem Beitrag vom 1. April 2025 beschrieben, welche Lücke das öffnet: Das Modell liest die ganze Beschreibung, der Nutzer sieht in der Oberfläche meist nur eine vereinfachte Fassung. Beim Tool Poisoning werden in dieser Beschreibung Anweisungen versteckt, die das Modell liest und der Nutzer nicht sieht. Das Beispiel von Invariant ist ein Werkzeug, das zwei Zahlen addiert:

Der Code des Servers tut nichts Schädliches, er addiert zwei Zahlen. Den Schaden richtet das Modell an: Es folgt der Anweisung in der Beschreibung, liest zwei Dateien und schickt ihren Inhalt im Argument sidenote an den Server. Die Anweisung verlangt außerdem, dem Nutzer nichts davon zu sagen. Invariant hat das Werkzeug mit Cursor ausprobiert und gezeigt, wie der Agent die Datei mcp.json des Nutzers preisgibt. Die MCP-Spezifikation verlangt von Clients, dem Nutzer die Eingaben eines Werkzeugs zu zeigen, bevor sie den Server aufrufen, damit keine Daten abfließen.

Invariant weist auf zwei weitere Punkte hin. Der erste ist der Rug Pull: Ein bösartiger Server kann die Beschreibung eines Werkzeugs ändern, nachdem der Client ihn freigegeben hat. Auch laut Spezifikation kann sich die Werkzeugliste eines Servers mit der Zeit ändern. Der zweite ist die Gegenmaßnahme, die Invariant empfiehlt: die Version des Servers und seiner Werkzeuge zu pinnen.

Die MCP-Spezifikation verwendet den Namen “tool poisoning” nicht, sieht das Problem aber genauso: Beschreibungen, die das Verhalten eines Werkzeugs erklären, gelten als nicht vertrauenswürdig, solange sie nicht von einem vertrauenswürdigen Server stammen. Der Security-Blog von Microsoft sagt dasselbe: Eine Änderung an der Beschreibung eines Werkzeugs kann das Verhalten des Agenten ebenso wirksam umlenken wie eine Änderung an seinem System-Prompt.

Es gibt auch eine Studie, die misst, wie oft dieser Angriff gelingt. MCPTox hat auf 353 Werkzeugen von 45 echten MCP-Servern 1.348 vergiftete Testfälle gebaut und sie mit 20 Modellkonfigurationen ausprobiert. Der durchschnittliche Angriffserfolg lag bei 36,5 %, die höchste Rate bei o1-mini mit 72,8 %. Am häufigsten lehnte Claude-3.7-Sonnet den Angriff ab, und selbst dort lag die Ablehnungsrate unter 3 %. Das sind Modelle aus dem Jahr 2025, in dem die erste Fassung des Papers entstand; heutige Modelle hat diese Studie nicht gemessen.

In den MCP Top 10 von OWASP, die noch im Beta-Stadium sind, ist der dritte Punkt (MCP03) Tool Poisoning. Die Detailseite zu diesem Punkt sagt, dass sich eine solche Beschreibung schon vor der Installation beim Lesen erkennen lässt, und nennt fünf Anzeichen. Die Frage „Der Code des Servers“ in der Checkliste unten stammt aus diesen Anzeichen.

Warum tut ein Agent beim Lesen eines Issues das Falsche?

Der zweite Weg führt über die Inhalte, die der Server liefert. Die Beschreibung des Werkzeugs kann sauber sein; holt das Werkzeug aber ein Issue, eine Webseite oder eine Chatnachricht, landet auch dieser Text im Kontext des Modells, und die Anweisung darin wird mitgelesen. Das nennt man indirekte Prompt Injection.

Ein Beispiel von Invariant Labs vom 26. Mai 2025 hat das mit dem offiziellen MCP-Server von GitHub gezeigt. Ein Angreifer eröffnet in einem öffentlichen Repository ein Issue. Bittet der Nutzer seinen Agenten, sich die offenen Issues anzusehen, liest der Agent dieses Issue, holt Informationen aus den privaten Repositorys des Nutzers in seinen Kontext und schreibt sie in einen Pull Request, den er selbst im öffentlichen Repository eröffnet. Die Autoren schreiben, das sei kein Fehler im Code des GitHub-MCP-Servers; das Problem liege in der Architektur des Agentensystems.

Die Gefahr liegt nicht in einer einzelnen Fähigkeit, sondern darin, dass sie zusammenkommen: Derselbe Agent kann Text von außen lesen, auf private Daten zugreifen und an eine Stelle schreiben, die alle sehen. Invariant empfiehlt, den Agenten pro Sitzung auf ein einziges Repository zu beschränken. Jeden Werkzeugaufruf freizugeben, reicht allein auch nicht: Laut den Autoren schalten viele Nutzer “Always Allow” ein und verfolgen die einzelnen Aktionen nicht mehr. Die Dokumentation von Claude Code warnt ebenso: “Servers that fetch external content can expose you to prompt injection risk.”

Derselbe Weg kann dazu führen, dass der Agent seine eigene MCP-Konfiguration schreibt. Laut dem NVD-Eintrag CVE-2025-54135 konnte in Cursor vor 1.3.9 eine indirekte Prompt Injection den Agenten dazu bringen, .cursor/mcp.json zu schreiben, wenn die Datei noch nicht existierte, und Code konnte ohne Freigabe des Nutzers laufen. Heute zählt Claude Code .mcp.json zu den geschützten Dateien und gibt einen Schreibzugriff darauf nie automatisch frei, außer in dem Modus, der alle Berechtigungsabfragen überspringt. Auch Cursor lässt den Agenten Konfigurationsdateien nicht ohne Freigabe ändern. Wenn ein Pull Request, den ein Agent geöffnet hat, die MCP-Datei anfasst, prüfen Sie, wer diese Änderung wollte.

Auch der Code des Servers selbst muss diesem Text standhalten. Laut MCP-Spezifikation ruft das Modell die Werkzeuge auf; das Modell schreibt also auch ihre Argumente. Wenn ein Text, den das Modell liest, es lenken kann, kann dieser Text auch das Argument bestimmen. Die NVD-Einträge zum Referenz-Git-MCP-Server (mcp-server-git) zeigen zwei Fehler, nach denen man in solchem Code suchen sollte:

Quelle: NVD-Einträge, 18. Oktober 2026. Die ersten beiden Einträge hat die NVD am 17. Dezember 2025 veröffentlicht.

Die Korrekturen zeigen auch, worauf zu achten ist: ein Argument ablehnen, das mit - beginnt, den angefragten Pfad mit aufgelösten symbolischen Links bestimmen und prüfen, ob er im erlaubten Ordner bleibt.

Wann starten die Tools einen MCP-Server aus dem Repository?

Jedes Tool lässt einen Server, der mit dem Repository kommt, durch eine andere Tür. Die Tabelle zeigt, was wir am 18. Oktober 2026 in der Dokumentation des jeweiligen Tools gelesen haben:

Quelle: die Dokumentation des jeweiligen Tools, 18. Oktober 2026. „Steht nicht in der Dokumentation“ heißt: Auf den Seiten, die wir an diesem Tag gelesen haben, fanden wir keinen Satz zu diesem Fall. Was in Gemini CLI mit den Servern im Repository passiert, solange das Ordnervertrauen ausgeschaltet ist, steht ebenfalls nicht in der Dokumentation. Dass Cursor seit Version 1.3 bei jeder Änderung erneut fragt, schreibt Check Point; in der Dokumentation von Cursor steht dieser Satz nicht.

Das häufigste Wort in der Tabelle ist Vertrauen. Die meisten Tools öffnen die Server im Repository nicht einzeln, sondern zusammen mit dem Vertrauen, das Sie einem Ordner oder einem Arbeitsbereich aussprechen. Deshalb rät die Dokumentation von VS Code, sich die MCP-Konfiguration anzusehen, bevor Sie einem Repository vertrauen, denn lokale MCP-Server können Code auf Ihrem Rechner ausführen.

Wichtig ist auch, mit wie vielen Klicks man an der Vertrauensfrage vorbeikommt. Adversa AI schreibt in seinem TrustFall-Beitrag vom 7. Mai 2026, dass die vier getesteten CLIs (Claude Code, Gemini CLI, Cursor CLI und Copilot CLI) die im Repository definierten MCP-Server ausführen konnten, sobald das Ordnervertrauen bestätigt war, und dass bei allen vieren “Yes/Trust” die Standardauswahl war. Laut dem Beitrag machten das in Claude Code 2.1.129 die ins Repository committeten Einstellungen enableAllProjectMcpServers und enabledMcpjsonServers möglich. Die heutige Dokumentation von Claude Code sagt, dass diese Einstellungen aus dem Repository in einem nicht vertrauenswürdigen Ordner ignoriert werden; was passiert, nachdem Sie dem Ordner vertraut haben, steht nicht in der Dokumentation.

Google hat Gemini CLI am 18. Juni 2026 für kostenlose Nutzer sowie für Abonnenten von Google AI Pro und Ultra eingestellt und sie auf Antigravity CLI verwiesen; mit einem kostenpflichtigen API-Schlüssel oder einer Firmenlizenz können Sie Gemini CLI weiter nutzen. Die Dokumentation von Antigravity CLI haben wir am 28. Oktober 2026 gelesen. Laut der MCP-Seite stehen die Server des Repositorys in .agents/mcp_config.json, die des Nutzers in ~/.gemini/config/mcp_config.json; auf die erste Datei sollten Sie in einem Pull Request achten. Ein MCP-Werkzeug, das in Ihren Berechtigungsregeln nicht vorkommt, fragt standardmäßig nach einer Freigabe, bevor es aufgerufen wird. Die CLI fragt auch, ob Sie dem Ordner vertrauen. Ob die Server aus dem Repository auf diese Antwort warten und ob die CLI erneut fragt, wenn sich die Konfiguration ändert, steht nicht in der Dokumentation.

Was passiert, wenn sich der Server nach der Freigabe ändert?

Die Freigabe wird einmal erteilt, der Server aber ändert sich weiter. Die Lücke, die Check Point Research MCPoison genannt hat, zeigte, wohin das führen kann: Cursor band das Vertrauen an den Namen des Servers und prüfte nicht, ob sich Befehl oder Argumente geändert hatten. Laut NVD-Eintrag (CVE-2025-54136) konnte in Cursor 1.2.4 und älter jeder, der in ein gemeinsames Repository schreiben durfte, einen harmlosen Server, den ein Teammitglied einmal freigegeben hatte, ohne Warnung und ohne neue Freigabeabfrage gegen einen bösartigen Befehl austauschen.

Check Point meldete die Lücke am 16. Juli 2025 an Cursor, und Cursor behob sie am 29. Juli 2025 mit Version 1.3. Laut Check Point verlangt seitdem jede Änderung an der Konfiguration, selbst ein zusätzliches Leerzeichen, eine neue Freigabe. In der Dokumentation von Cursor haben wir keinen Satz gefunden, der dieses Verhalten beschreibt.

Die Dokumentation der anderen Tools beantwortet diese Frage entweder anders oder gar nicht. VS Code ist eindeutig: In einem Arbeitsbereich, dem Sie vertrauen, können die Server aus .vscode/mcp.json und aus .mcp.json im Stammverzeichnis ohne eigene MCP-Freigabe starten, “including after their configuration changes”. In Claude Code speichert die Freigabeliste (enabledMcpjsonServers) die Namen der Server; ob es erneut fragt, wenn sich unter demselben Namen der Befehl ändert, steht nicht in der Dokumentation. Auch die MCP-Dokumentation von Cursor, Codex und Gemini CLI enthält dazu keinen Satz.

Zum Vergleich: Für Hooks beantworten Codex und Gemini CLI dieselbe Frage. Codex verlangt, dass Sie die genaue Definition eines Hooks aus dem Repository prüfen und freigeben, bevor er läuft. Gemini CLI behandelt einen Hook, dessen Name oder Befehl sich geändert hat, als neuen, nicht vertrauenswürdigen Hook und warnt, bevor er läuft. Für MCP-Server enthalten beide Dokumentationen keinen ähnlichen Satz.

Auch die Werkzeuge eines Servers können sich ändern, während er läuft. Der Server meldet das mit einer Benachrichtigung (list_changed); Claude Code lädt die Werkzeugliste in einer interaktiven Sitzung neu, wenn diese Benachrichtigung kommt. Ob die geänderten Beschreibungen dem Nutzer angezeigt werden, steht nicht in der Dokumentation.

Kurz gesagt: Die Freigabe auf Ihrem Laptop hat die erste Fassung des Servers gesehen. Spätere Fassungen sehen Sie, auch wenn der Name gleich bleibt, im Diff des Pull Requests.

Lädt ein Agent in der CI die MCP-Server des Repositorys?

In einem nicht interaktiven Lauf ist niemand da, der etwas freigibt. Die Dokumentation von Claude Code sagt das klar: In claude -p-Läufen, Agent-SDK-Sitzungen und Cloud-Sitzungen kann Claude Code die Freigabeabfrage nicht anzeigen und lädt Projektserver ohne Rückfrage. Die Tabelle in der Dokumentation zu Berechtigungen nimmt einen claude -p-Lauf in einem Ordner, dem nie vertraut wurde, und beschreibt seine .mcp.json-Server in einem Satz: “Connected without asking, approved or not.”

Bevor Sie claude -p in einem Repository ausführen, das Sie nicht selbst geschrieben haben, nennt die Dokumentation von Claude Code diese Wege:

• --setting-sources user: liest weder die Einstellungsdateien des Projekts noch dessen .mcp.json.
• --bare: liest aus dem Projekt keine Hooks, Skills, Subagenten, Plugins und .mcp.json-Server; der env-Block des Projekts gilt trotzdem.
• --strict-mcp-config: nutzt nur die Server, die Sie mit --mcp-config übergeben.
• disabledMcpjsonServers: sperrt einen Server über seinen Namen, in jedem Berechtigungsmodus.

Die anderen Tools verhalten sich anders. Der Prompt-Modus von Copilot CLI (copilot -p) lädt Projektserver von sich aus, wenn dem Ordner schon vertraut wird, und überspringt sie sonst. In Cursor CLI gibt das Flag --approve-mcps alle MCP-Server automatisch frei, und --trust vertraut im Headless-Modus dem Arbeitsbereich ohne Rückfrage. Fügt eine Workflow-Datei eines dieser Flags hinzu, lesen Sie das ebenfalls wie eine MCP-Änderung. Die Dokumentation von Codex und Gemini CLI sagt nicht, was in einem nicht interaktiven Lauf mit einem Server aus dem Repository passiert.

Bei der GitHub Action, die auf Pull Requests läuft, gibt es noch eine Unterscheidung. Die Sicherheitsdokumentation von claude-code-action schreibt, dass die Action auf einem Pull Request eine feste Liste von Claude-Konfigurationspfaden (8 Pfade, darunter .mcp.json) aus dem Basis-Branch wiederherstellt, bevor Claude startet; die Fassungen aus dem Pull Request liegen nur zum Nachschlagen in einem eigenen Ordner. Der Rest des Arbeitsverzeichnisses bleibt im Stand des Pull Requests. Die tiefer liegende claude-code-base-action stellt dagegen nichts wieder her. Der TrustFall-Beitrag von Adversa hatte geschrieben, dass bei der Standardnutzung der offiziellen Action die Vertrauensabfrage gar nicht erscheint und der Angriff gegen Pull-Request-Branches ganz ohne menschliches Zutun läuft; die heutige Dokumentation der Action beschreibt die Wiederherstellung oben.

Beim Cloud-Agenten von GitHub Copilot ist die MCP-Konfiguration dagegen keine Datei im Repository: Sie wird in den Einstellungen des Repositorys auf GitHub.com eingetragen, und Copilot code review nutzt dieselbe Konfiguration. Deshalb erscheint sie nicht im Diff des Pull Requests. Laut Dokumentation nutzt der Agent diese Werkzeuge, ohne um Freigabe zu bitten; GitHub empfiehlt deshalb, nur lesende Werkzeuge einzeln auf eine Allowlist zu setzen.

Was steht auf der MCP-Risikoliste von OWASP?

Die MCP Top 10 von OWASP fassen die MCP-spezifischen Risiken unter 10 Überschriften zusammen. Die Seite selbst sagt, dass die Liste im Beta-Stadium ist. Am 18. Oktober 2026 lauteten die Überschriften auf owasp.org so:

Quelle: owasp.org, 18. Oktober 2026. Das GitHub-Repository des Projekts führt MCP06 unter dem Namen “Intent Flow Subversion” und nennt als nächste Version Oktober 2026; die Namen können sich ändern.

Nutzen Sie die Liste nicht als Standard, sondern als gemeinsames Vokabular: Sie hilft, einer Feststellung einen Namen zu geben. Die meisten Fragen unten entsprechen MCP01, MCP03, MCP04, MCP05 und MCP06.

Was prüft man in einem Pull Request, der eine MCP-Datei ändert?

Alles bisher läuft auf einen Schluss hinaus: Der Freigabedialog hat die erste Fassung des Servers gesehen, jede spätere Änderung können Sie im Pull Request lesen. Das Beispiel unten zeigt drei Dinge auf einmal, die ein Pull Request in einer MCP-Datei ändern kann:

Die erste Änderung übersieht man am leichtesten: Der Name docs ist gleich geblieben, aber jetzt läuft ein anderes Programm, und zwar ein Skript aus dem Repository. Dieses Skript kann sich mit diesem oder späteren Pull Requests ändern; was der Server tut, hängt jetzt davon ab, dass diese Datei geprüft wird. Der zweite Server lädt bei jedem Start die gerade aktuelle Version des Pakets herunter und bekommt ein Token aus der Umgebung.

Gehen Sie bei so einem Diff diese Fragen der Reihe nach durch:

• Befehl, Argumente und Adresse. Der Sicherheitsleitfaden von MCP verlangt von Clients, die einen Server mit einem Klick einrichten, den Befehl, der ausgeführt wird, samt Argumenten ungekürzt anzuzeigen. Im Pull Request haben Sie diese Zeilen ohnehin vor sich; führt der Befehl ein Skript aus dem Repository aus, lesen Sie auch dieses Skript. Prüfen Sie bei einem entfernten Server, wem die Adresse gehört und ob sie https nutzt. Der Leitfaden beschreibt außerdem gesondert, dass eine OAuth-Adresse, die ein bösartiger Server liefert, bis zur Codeausführung auf dem Client führen kann.
• Version. @latest oder ein Paketname ohne Version kann bei jedem Start anderen Code bringen. Invariant empfiehlt, die Version des Servers und seiner Werkzeuge zu pinnen; auf der Liste von OWASP ist die Lieferkette ein eigener Punkt (MCP04).
• Ein Server, der sich unter gleichem Namen ändert. Aus genau dieser Zeile entstand MCPoison. Hängt die Freigabe an einem Namen, kann ein neuer Befehl hinter der alten Freigabe stehen, solange der Name gleich bleibt. Lesen Sie eine solche Änderung wie einen neuen Server.
• Freigaben, die mit dem Pull Request kommen. Claude Code schreibt die Einstellungen enableAllProjectMcpServers und enabledMcpjsonServers in .claude/settings.local.json, wenn Sie eine Freigabe erteilen; sie halten eine persönliche Entscheidung fest. Stehen sie in der geteilten .claude/settings.json, wird die Freigabe einer Person an alle verteilt. In Gemini CLI überspringt "trust": true alle Bestätigungen für diesen Server, und die Dokumentation empfiehlt das nur für Server, die Sie vollständig kontrollieren; ob es auch gilt, wenn es in der Projektdatei steht, steht nicht in der Dokumentation.
• Secrets. Prüfen Sie, welche Variable in die Felder env und headers geht und worauf dieses Token zugreifen kann. Claude Code und Cursor können einen Schlüssel aus einer Umgebungsvariablen lesen, statt ihn in die Datei zu schreiben; das holt das Secret aus der Datei, verhindert aber nicht, dass es beim Server ankommt. Gemini CLI gibt sensible Variablen aus der Basisumgebung nicht an den Server weiter, wertet aber eine ausdrücklich in das Feld env geschriebene Variable als informierte Einwilligung des Nutzers und schwärzt sie nicht. Wer diese Zeile im Pull Request liest, ist die Person, die diese Einwilligung gibt.
• Hilfsbefehle. Claude Code führt headersHelper als “arbitrary shell command” aus; in Codex ist http_headers_helper ebenfalls ein lokaler Befehl. Lesen Sie sie wie den Server selbst.
• Werkzeuge, die fremden Text lesen. Kommt ein Server, der Issues, Webseiten oder Chats liest, neben einen Server, der auf private Daten zugreift, sehen Sie sich beide zusammen an. Das GitHub-Beispiel war die Folge genau dieses Paars.
• Der Code des Servers. Liegt der Code im Pull Request, achten Sie auf Argumente, die mit - beginnen, und auf Pfade, die aus dem Repository hinausführen (die Git-MCP-Einträge oben). Suchen Sie in den Beschreibungen der Werkzeuge nach den Anzeichen, die OWASP MCP03 nennt: Befehlssätze, die sich an das Modell richten, sensible Dateipfade wie ~/.ssh oder .env, Sätze, die etwas an eine Adresse „senden“ wollen, Zeichen ohne Breite und Anweisungen, die in HTML-Kommentaren versteckt sind.
• CI. Startet der Workflow den Agenten auf dem Branch des Pull Requests, mit geladenen Projekteinstellungen? Prüfen Sie bei Claude Code, ob --setting-sources user oder --strict-mcp-config gesetzt ist, und bei Cursor CLI, ob das Flag --approve-mcps dabei ist.

Diese Fragen in eine Regeldatei zu schreiben, reicht allein nicht: Gelesen wird eine Änderung erst im Review. Dasselbe Review gilt für die Hooks in .claude/settings.json, die wir uns im Beitrag über Hooks gesondert angesehen haben. Wie die Sicherheitsdokumentation von Claude Code erinnert, zeigt ein Blick in .mcp.json nicht jeden Server, den eine Sitzung laden kann: Es gibt auch Server aus den Benutzereinstellungen und aus Plugins.

Auch ein Code-Review-Bot steht nicht außerhalb dieses Problems: Er ist ebenfalls ein Modell, das Text liest, den der Autor des Pull Requests geschrieben hat. In diffox wird in dem Schritt, der entscheidet, ob eine Feststellung mit der Begründung „Der Autor hat das absichtlich gemacht“ verworfen wird, die Beschreibung des Pull Requests zwischen Tags gesetzt, und dem Modell wird gesagt, dass es sich um Daten handelt und nicht um eine Anweisung; ein Tag, das in der Beschreibung selbst steht, wird unschädlich gemacht. Der Security Agent, der bei jedem Review läuft, sucht Injection, kaputte Authentifizierung und Autorisierung, geleakte Secrets, SSRF sowie unsichere Deserialisierung oder Pfadbehandlung (wie diffox arbeitet, haben wir in einem eigenen Beitrag beschrieben).

Häufige Fragen

Was ist MCP Tool Poisoning?

Beim Tool Poisoning werden in der Beschreibung eines MCP-Werkzeugs Anweisungen versteckt, die das Modell liest und der Nutzer nicht sieht. Im Beispiel von Invariant Labs verlangt die Beschreibung eines Werkzeugs, das zwei Zahlen addiert, vom Modell, den SSH-Schlüssel des Nutzers zu lesen, ihn in einem Argument an den Server zu schicken und dem Nutzer nichts davon zu sagen. In den OWASP MCP Top 10 ist es der dritte Punkt (MCP03). Man erkennt es beim Lesen der Beschreibung: Befehlssätze an das Modell, sensible Dateipfade und unsichtbare Zeichen sind die bekanntesten Anzeichen.

Was sind die OWASP MCP Top 10, und welche Version ist aktuell?

Die Liste, in der OWASP 10 MCP-spezifische Risiken sammelt. Stand 18. Oktober 2026 ist die Liste auf owasp.org im Beta-Stadium, und ihre Punkte sind nach dem Muster „MCP01:2025“ nummeriert; sie reicht von Token Mismanagement & Secret Exposure bis Context Injection & Over-Sharing. Das GitHub-Repository des Projekts nennt als nächste Version Oktober 2026, und ein Punkt heißt dort anders als auf der Website. Wenn Sie einen Punkt zitieren, geben Sie auch sein Datum an.

Sollte man .mcp.json ins Repository committen?

Die Dokumentation von Claude Code empfiehlt es, damit alle im Team dieselben Werkzeuge nutzen. Sobald Sie die Datei committen, ist sie Teil des Codes und sollte wie Code geprüft werden: Befehl, Version, Umgebungsvariablen und Freigabe-Einstellungen. Persönliche Freigaben (wie enabledMcpjsonServers) gehören dagegen in .claude/settings.local.json, wohin Claude Code sie auch selbst schreibt.

Startet Claude Code MCP-Server aus dem Repository ohne Rückfrage?

In einer interaktiven Sitzung nicht: Es fragt für jeden Server in .mcp.json einzeln nach einer Freigabe und ignoriert in einem nicht vertrauenswürdigen Ordner Freigabe-Einstellungen, die ins Repository committet wurden. In claude -p-Läufen, Agent-SDK-Sitzungen und Cloud-Sitzungen kann es die Freigabeabfrage dagegen nicht anzeigen und lädt Projektserver deshalb ohne Rückfrage. Verhindern lässt sich das mit --setting-sources user, --bare, --strict-mcp-config oder disabledMcpjsonServers.

Wie schaltet man MCP-Server aus dem Repository ab, wenn ein Coding-Agent in der CI läuft?

In Claude Code liest --setting-sources user weder die Projekteinstellungen noch .mcp.json; --strict-mcp-config nutzt nur die Server, die Sie übergeben. Auf Pull Requests stellt claude-code-action die Datei .mcp.json aus dem Basis-Branch wieder her. Der -p-Modus von Copilot CLI überspringt Projektserver in einem nicht vertrauenswürdigen Ordner. In Cursor CLI gibt --approve-mcps alle Server frei; setzen Sie dieses Flag nicht in einem Job ein, der auf dem Branch des Pull Requests läuft. Die Dokumentation von Codex und Gemini CLI beschreibt diesen Fall nicht.

Erkennt ein KI-Code-Review-Tool eine MCP-Änderung?

Das hängt vom Tool ab. diffox liest den Diff des Pull Requests, und der Security Agent läuft bei jedem Review: Er sucht Injection, kaputte Authentifizierung und Autorisierung, geleakte Secrets, SSRF sowie unsichere Deserialisierung oder Pfadbehandlung. Eine eigene Regel speziell für MCP hat diffox nicht; die Fragen aus diesem Beitrag stellt die Person, die das Review macht. Fragen Sie bei der Wahl eines Code-Review-Tools auch, wie es die Beschreibung des Pull Requests liest: In diffox liest der Schritt, der prüft, ob eine Feststellung beabsichtigt war, die Beschreibung als Daten, nicht als Anweisung.