MCP-Sicherheit: Tool Poisoning, bösartige Server und Supply-Chain-Exploits

Das Model Context Protocol (MCP) hat sich innerhalb weniger Monate vom Nischenstandard zum De-facto-Bindeglied zwischen KI-Agenten und externen Werkzeugen entwickelt. Genau diese Reichweite macht es zu einer attraktiven Angriffsfläche. Wer einen Agenten an Dateisysteme, Datenbanken, Ticketsysteme oder Zahlungs-APIs anbindet, baut keine harmlose Integrationsschicht, sondern eine Tool-Lieferkette, deren Vertrauensgrenzen sich oft niemand bewusst gemacht hat. Dieser Leitfaden ordnet die MCP-Bedrohungen entlang eines klaren Bedrohungsmodells und zeigt, wie eine MCP-Integration aussieht, die einem gezielten Angriff standhält.

Was bedeutet MCP-Sicherheit konkret?

MCP-Sicherheit bedeutet, die gesamte Kette zwischen KI-Agent und angebundenem Werkzeug so abzusichern, dass weder ein bösartiger MCP-Server noch eine manipulierte Tool-Beschreibung das Verhalten des Agenten übernehmen, Daten abfließen lassen oder mit überhöhten Rechten handeln kann. Der entscheidende Punkt: Bei MCP wird die Tool-Beschreibung Teil des Kontexts, in dem das Sprachmodell denkt. Was der Server als Beschreibung liefert, liest das Modell als Anweisung — der Mensch sieht diesen Text in der Regel nicht. Damit verschiebt sich die klassische Frage „Ist mein Code sicher?“ zu einer neuen Frage: „Vertraue ich allem, was meine Werkzeuge mir in den Kontext schreiben?“

Die kurze, zitierfähige Antwort lautet: MCP ist nicht von Natur aus unsicher, aber die Standardannahmen der meisten Integrationen sind zu großzügig. Tool-Beschreibungen werden ohne Prüfung übernommen, Server laufen mit weit mehr Rechten als nötig, und Vertrauensgrenzen zwischen verschiedenen Servern existieren oft gar nicht. Sicherheit entsteht erst, wenn Sie diese drei Annahmen aktiv umkehren.

Warum ist MCP überhaupt eine eigene Angriffsfläche?

Ein klassischer API-Aufruf folgt einem festen Vertrag: Der Entwickler kennt Endpunkt, Parameter und erwartete Antwort. Bei MCP entscheidet hingegen das Sprachmodell zur Laufzeit, welches Werkzeug es mit welchen Argumenten aufruft — und es trifft diese Entscheidung auf Basis der Beschreibungen, die der MCP-Server selbst liefert. Dadurch wandert ein Teil der Kontrolllogik aus dem Code in natürlichsprachlichen Text, den ein Angreifer beeinflussen kann.

Diese Architektur bringt drei strukturelle Eigenschaften mit sich, die jede einzeln zur Schwachstelle werden kann. Erstens ist die Tool-Beschreibung aktiver Kontext, nicht passive Dokumentation. Zweitens kann ein Agent mehrere Server gleichzeitig nutzen, ohne dass diese voneinander isoliert sind. Drittens handelt der MCP-Server fast immer mit den Berechtigungen eines Dienstkontos, das breiter angelegt ist als die Aufgabe, die der Agent gerade erledigt. Das Bedrohungsmodell von MCP ergibt sich direkt aus diesen drei Eigenschaften.

Wie sieht die Angriffsfläche von MCP aus?

Die Angriffsfläche von MCP lässt sich entlang der Kette vom Modell bis zum Zielsystem in vier Zonen gliedern. Wer diese Zonen kennt, kann jede Bedrohung einer konkreten Stelle zuordnen, statt vage von „KI-Risiken“ zu sprechen.

Die erste Zone ist der Host beziehungsweise Client — also die Anwendung, in der der Agent läuft (etwa eine IDE, ein Chat-Client oder ein eigener Agenten-Stack). Hier entscheidet sich, welche Server überhaupt verbunden werden und ob Tool-Aufrufe vor der Ausführung geprüft werden. Die zweite Zone ist der Transportweg zwischen Client und Server, der bei lokalen Servern über Standard-Ein-/Ausgabe und bei entfernten Servern über HTTP läuft. Die dritte Zone ist der MCP-Server selbst, der Werkzeuge bereitstellt und im Namen des Nutzers handelt. Die vierte Zone sind die nachgelagerten Systeme — Datenbanken, Dateisysteme, fremde APIs —, auf die der Server tatsächlich zugreift.

Jede dieser Zonen hat ein eigenes Vertrauensproblem. Beim Host geht es um die Frage, welchen Servern man Werkzeuge in den Kontext schreiben lässt. Beim Transport geht es um Authentifizierung und Manipulationsschutz. Beim Server geht es um die Integrität der Tool-Definitionen und um die Frage, ob der Server-Anbieter selbst vertrauenswürdig ist. Bei den nachgelagerten Systemen geht es um das Prinzip der minimalen Rechte. Die folgenden Abschnitte gehen die konkreten MCP-Bedrohungen durch und ordnen sie diesen Zonen zu.

Welche MCP-Bedrohungen sind die wichtigsten?

Die relevanten Bedrohungen lassen sich auf vier Kernklassen verdichten, die in der Forschung und in den dokumentierten Vorfällen immer wieder auftauchen: bösartige Server, Tool Poisoning, überhöhte Rechte und fehlende Vertrauensgrenzen. Sie hängen zusammen, lassen sich aber sauber unterscheiden.

Bedrohung	Zone	Kern des Angriffs	Erste Gegenmaßnahme
Bösartiger MCP-Server	Server	Server liefert von Anfang an schädliche Werkzeuge oder Beschreibungen	Nur geprüfte, festgepinnte Server zulassen
Tool Poisoning	Server/Host	Verborgene Anweisungen in der Tool-Beschreibung steuern das Modell	Beschreibungen anzeigen, prüfen, Aufrufe bestätigen
Rug Pull	Server/Host	Werkzeug ändert sein Verhalten nach erfolgter Freigabe	Versionspinning, Änderungs-Alarme
Confused Deputy	Server/Downstream	Server handelt mit breiteren Rechten als der Nutzer	Tokens nicht durchreichen, Rechte minimieren
Cross-Tool-Kontamination	Host	Ein Server überschreibt Anweisungen anderer Server	Server isolieren, Kontext trennen

Was ist ein bösartiger MCP-Server?

Ein bösartiger MCP-Server ist der direkteste Angriff: Der Server ist von Beginn an darauf ausgelegt, dem Agenten zu schaden. Weil ein Server nicht nur Werkzeuge anbietet, sondern auch deren Beschreibungen liefert, kann er Daten des Nutzers abgreifen, das Verhalten des Agenten umlenken und sogar Anweisungen überschreiben, die von anderen, vertrauenswürdigen Servern stammen.

Das Tückische daran ist die Bezugsquelle. MCP-Server werden zunehmend über öffentliche Verzeichnisse und Paket-Ökosysteme verteilt, ähnlich wie Bibliotheken in npm oder PyPI. Damit erbt MCP sämtliche bekannten Probleme der Software-Lieferkette: Typosquatting, übernommene Pakete, kompromittierte Maintainer-Konten. Ein Entwickler, der einen Server „weil er nützlich aussieht“ einbindet, trifft faktisch dieselbe Vertrauensentscheidung wie bei einer beliebigen Abhängigkeit — nur dass dieser Server unmittelbaren Zugriff auf den Kontext und die Werkzeuge des Agenten erhält.

Was bedeutet Tool Poisoning genau?

Tool Poisoning ist die für MCP charakteristischste Bedrohung. Dabei bettet ein Angreifer verborgene Anweisungen in die Metadaten eines Werkzeugs ein — typischerweise in die Tool-Beschreibung. Das Modell liest diesen Text als Teil seines Auftrags, der Nutzer sieht ihn nicht. Eine Beschreibung, die nach außen „Liest den Inhalt einer Datei“ lautet, kann im verborgenen Teil die Anweisung enthalten, zusätzlich Zugangsdaten auszulesen und an einen Parameter anzuhängen.

Der Grund, warum dieser Angriff so wirksam ist, liegt im Vertrauensmodell der Clients: Die aktuelle Praxis vieler MCP-Clients schenkt Tool-Beschreibungen zu viel Vertrauen, ohne ausreichende Prüfung oder Transparenz gegenüber dem Nutzer. Sicherheitsforscher beschreiben Tool-Beschreibungen treffend als „Code, der im Schlussfolgern des Modells ausgeführt wird“. Damit gelten für sie dieselben Angriffsmuster wie für klassischen Code: Injection, Manipulation, Kompromittierung der Lieferkette und Rechtemissbrauch.

Eine besonders heimtückische Variante ist der Rug Pull: Ein Werkzeug besteht zunächst die anfängliche Prüfung, ändert nach der Freigabe aber stillschweigend seine Definition und schmuggelt schädliche Funktionalität nach. Da die meisten MCP-Clients den Nutzer nicht warnen, wenn sich eine Tool-Beschreibung nach der Freigabe ändert, bleibt diese Manipulation oft unbemerkt. Eine verwandte Variante ist die Cross-Tool-Kontamination, bei der ein bösartiges Werkzeug die Anweisungen eines anderen, vertrauenswürdigen Werkzeugs überschreibt.

Warum sind überhöhte Rechte so gefährlich?

Überhöhte Rechte sind nicht spezifisch für MCP, werden aber durch die Architektur verschärft. Ein MCP-Server handelt im Namen des Nutzers, läuft praktisch aber unter einem Dienstkonto, das oft mit weit breiteren Berechtigungen ausgestattet ist als die konkrete Aufgabe verlangt. Wenn ein Datenbank-Server mit einem Konto läuft, das Lese- und Schreibrechte auf alle Tabellen hat, der Agent aber nur eine einzige Tabelle abfragen soll, dann ist die Differenz zwischen „darf“ und „braucht“ die Angriffsfläche.

Hier setzt das Confused-Deputy-Problem an. Selbst wenn Sie ein vergiftetes Werkzeug erkennen, ermöglichen unsauber zugeschnittene Tokens dem Angreifer den Zugriff über legitime Werkzeuge. Der Server agiert als „verwirrter Stellvertreter“: Er nutzt seine breiten Rechte, um eine Aktion auszuführen, die der eigentliche Nutzer niemals hätte durchführen dürfen. OAuth-Fehlkonfigurationen machen daraus im schlimmsten Fall einen Einzeiler-Fehler — etwa, wenn ein Server ein erhaltenes Token unverändert an eine vorgelagerte API weiterreicht.

Genau diesen Fall hat die MCP-Spezifikation adressiert: Die Revision vom Juni 2025 untersagt MCP-Servern ausdrücklich, Tokens an vorgelagerte APIs durchzureichen, und schreibt eine saubere Trennung vor. Ergänzend adressieren Resource Indicators nach RFC 8707 das Confused-Deputy-Problem, indem ein Token explizit an die Ressource gebunden wird, für die es gedacht ist.

Was bedeutet „fehlende Vertrauensgrenzen“?

Eine Vertrauensgrenze ist die Linie, an der Sie aufhören, einer Eingabe blind zu glauben, und anfangen, sie zu prüfen. Das Grundproblem vieler MCP-Integrationen ist, dass diese Linie nirgends gezogen wird. Der Agent behandelt alle verbundenen Server gleich, vermischt deren Beschreibungen im selben Kontext und prüft Werkzeugantworten nicht, bevor er auf ihrer Basis die nächste Aktion plant.

Konkret fehlt es an drei Grenzen. Zwischen den Servern: Verschiedene Server sollten sich nicht gegenseitig beeinflussen können, tun es im gemeinsamen Kontext aber oft doch. Zwischen Daten und Anweisung: Inhalte, die ein Werkzeug zurückliefert (etwa der Text einer abgerufenen Webseite), dürfen nicht automatisch als Anweisung an das Modell gelten — sonst wird jede abgerufene Seite zum potenziellen Einfallstor für indirekte Prompt Injection. Und zwischen Lesen und Handeln: Ein Werkzeug, das Daten liest, sollte nicht ohne Weiteres ein Werkzeug auslösen können, das Daten verändert oder versendet.

Wie integriert man MCP-Server sicher?

Sichere MCP-Integration ist kein einzelnes Produkt, sondern eine Reihe von Entscheidungen, die jede der vier Zonen absichern. Die folgenden Prinzipien lassen sich unabhängig vom konkreten Agenten-Stack umsetzen und bauen direkt auf dem Bedrohungsmodell auf.

Wie wählt und pinnt man MCP-Server vertrauenswürdig aus?

Behandeln Sie jeden MCP-Server wie eine externe Abhängigkeit mit Codeausführungsrechten — denn nichts anderes ist er. Das bedeutet erstens: nur Server aus nachvollziehbarer Herkunft einsetzen, idealerweise selbst gehostet oder aus einem geprüften internen Verzeichnis. Zweitens: jede Server-Version festpinnen, statt automatisch die neueste zu ziehen. Drittens: die Tool-Definitionen bei der Aufnahme einmal vollständig auslesen und als Referenz speichern, sodass jede spätere Änderung auffällt.

Das letzte Element ist die direkte Gegenmaßnahme gegen Rug Pulls. Wenn Sie einen Hash über die Tool-Definitionen bilden und bei jedem Verbindungsaufbau vergleichen, schlägt eine nachträgliche Manipulation sofort Alarm — unabhängig davon, ob der Client von sich aus warnt. Für entfernte Server ist außerdem die Frage der Anbieter-Reputation zentral: Ein Server, der von einem nicht verifizierbaren Dritten betrieben wird, sieht jeden Tool-Aufruf und jede zurückgegebene Antwort im Klartext.

Wie macht man Tool-Beschreibungen sichtbar und prüfbar?

Die wirksamste Einzelmaßnahme gegen Tool Poisoning ist, die Lücke zwischen dem, was das Modell sieht, und dem, was der Mensch sieht, zu schließen. Zeigen Sie die vollständige Tool-Beschreibung an, bevor ein Server freigegeben wird — nicht nur den hübschen Namen, sondern den gesamten Text, den auch das Modell erhält. Prüfen Sie diesen Text auf eingebettete Anweisungen, ungewöhnliche Aufforderungen oder Verweise auf andere Werkzeuge.

Ergänzend sollten sicherheitskritische Tool-Aufrufe eine ausdrückliche Bestätigung erfordern. Wenn ein Agent eine Datei löschen, eine Zahlung auslösen oder Daten nach außen senden will, ist eine Mensch-im-Prozess-Bestätigung kein Komfortverlust, sondern die letzte Grenze gegen einen gekaperten Kontext. Automatisierte Prüfungen können dies skalieren: Scanner, die Tool-Beschreibungen auf bekannte Poisoning-Muster untersuchen, fangen einen Teil der Angriffe ab, bevor ein Werkzeug überhaupt in den Kontext gelangt.

Wie setzt man minimale Rechte und saubere Authentifizierung durch?

Das Prinzip der minimalen Rechte ist bei MCP keine Kür, sondern die Grundlage. Jeder Server sollte ausschließlich mit den Berechtigungen laufen, die seine konkreten Werkzeuge tatsächlich benötigen — eigene, eng zugeschnittene Dienstkonten statt geteilter Administratorrechte. Wenn ein Server nur lesen muss, darf sein Konto nicht schreiben dürfen.

Für die Authentifizierung gelten die Vorgaben der jüngeren MCP-Spezifikation als Mindeststandard. Tokens werden nicht an vorgelagerte APIs durchgereicht; stattdessen wird die Autorisierung an einen externen Identitätsanbieter delegiert, was eigenen, fehleranfälligen Code reduziert. Resource Indicators nach RFC 8707 binden jedes Token an die Ressource, für die es bestimmt ist, und entschärfen damit das Confused-Deputy-Problem an der Wurzel. Für entfernte Server gehört Transportverschlüsselung selbstverständlich dazu.

Wie zieht man Vertrauensgrenzen im Agenten ein?

Die letzte Säule ist die Isolation. Behandeln Sie alles, was ein Werkzeug zurückliefert, als nicht vertrauenswürdige Daten — nicht als Anweisung. Inhalte aus abgerufenen Webseiten, Dokumenten oder Datenbankfeldern dürfen das Verhalten des Agenten nicht direkt umsteuern; sie gehören klar als „Daten“ markiert und vom Anweisungsteil getrennt. Das ist die Hauptverteidigung gegen indirekte Prompt Injection, die über vergiftete Inhalte statt über vergiftete Beschreibungen läuft.

Wo es der Anwendungsfall erlaubt, sollten Server gegeneinander isoliert werden, sodass die Beschreibungen des einen nicht den Kontext des anderen überschreiben können. Außerdem hilft eine Trennung nach Wirkung: Lese-Werkzeuge und schreibende oder sendende Werkzeuge in getrennten Vertrauensstufen führen, sodass ein kompromittierter Lesepfad nicht automatisch zu einer schädlichen Aktion eskaliert. Schließlich gehört Protokollierung dazu — wer jeden Tool-Aufruf samt Argumenten mitschreibt, kann einen Angriff im Nachhinein nachvollziehen und das Bedrohungsmodell mit echten Daten schärfen.

Wer ist im MCP-Bedrohungsmodell wofür verantwortlich?

Sicherheit scheitert oft an unklaren Zuständigkeiten. Im MCP-Ökosystem teilen sich drei Rollen die Verantwortung, und keine kann sie vollständig delegieren.

Der Host- beziehungsweise Client-Anbieter ist dafür verantwortlich, dass Tool-Beschreibungen sichtbar sind, dass Änderungen Alarm auslösen und dass sicherheitskritische Aufrufe bestätigt werden müssen. Der Server-Betreiber verantwortet die Integrität der Werkzeuge, das Prinzip der minimalen Rechte und eine spezifikationskonforme Authentifizierung ohne Token-Durchreichung. Der Integrator beziehungsweise das Anwendungsteam schließlich entscheidet, welche Server überhaupt vertraut werden, zieht die Vertrauensgrenzen im eigenen Agenten ein und behandelt jeden Server als prüfpflichtige Abhängigkeit.

Diese Aufteilung erklärt auch, warum sich MCP-Sicherheit nicht „einkaufen“ lässt. Selbst der sicherste Client schützt nicht vor einem überprivilegierten Server, und der best abgesicherte Server hilft nicht, wenn der Integrator ihm blind alle Rechte überlässt. Erst das Zusammenspiel aller drei Rollen ergibt eine belastbare Tool-Lieferkette.

Fazit: MCP-Sicherheit ist Lieferkettensicherheit

Die zentrale Erkenntnis dieses Leitfadens lautet: MCP-Bedrohungen sind keine exotischen KI-Risiken, sondern eine moderne Ausprägung bekannter Lieferketten- und Rechteprobleme — verschärft dadurch, dass natürlichsprachliche Beschreibungen zur aktiven Steuerungslogik werden. Wer die vier Zonen kennt, die vier Kernbedrohungen unterscheidet und die vier Schutzprinzipien umsetzt, verwandelt eine offene Angriffsfläche in eine kontrollierte Integration.

Praktisch heißt das: Server wie Abhängigkeiten prüfen und pinnen, Tool-Beschreibungen sichtbar und prüfbar machen, minimale Rechte und spezifikationskonforme Authentifizierung durchsetzen und klare Vertrauensgrenzen zwischen Servern, zwischen Daten und Anweisung sowie zwischen Lesen und Handeln ziehen. Keine dieser Maßnahmen ist neu — neu ist nur der Kontext, in dem sie angewendet werden müssen. Genau darin liegt die Chance: Teams, die solide Lieferketten- und Berechtigungspraxis beherrschen, haben für MCP bereits das halbe Bedrohungsmodell im Griff.