MCP-Sicherheit verhindert, dass die Tools, die Ihr KI-Agent über das Model Context Protocol (MCP) erreicht, gegen Sie eingesetzt werden. Jede Verbindung läuft über ein Programm namens MCP-Server, sodass jeder Fehler und jede dort eingeschleuste Anweisung zu Ihrem Problem wird. Zu den Hauptrisiken gehören versteckte Befehle in den Antworten eines Tools, schädliche Änderungen nach der Freigabe und Anfragen, die ohne Prüfung an beliebige Adressen gehen.
Ihre Entwickler können an einem Nachmittag ein neues Tool an Ihre KI anschließen, oft mit einem von GitHub kopierten Server, den sonst niemand geprüft hat. Ab diesem Moment teilt dieser Code den Zugriff Ihres Agenten auf Daten und Aktionen. 2026 mussten sogar Google und JPMorgan Chase denselben Fehler in MCP-Software beheben, die ihre eigenen Ingenieure gebaut hatten, und jemand versuchte, einen bösartigen Server innerhalb von 74 Minuten in 23 KI-Projekte einzuschleusen.
Beim KI-Agent-Testing prüfen die Spezialisten von QAwerk jede Verbindung so, wie es ein Angreifer tun würde. Unsere Bug Crawls, bei denen wir beliebte Apps testen und unsere Funde veröffentlichen, zeigen, warum das wichtig ist. Bei Otter.ai, einem KI-Meeting-Assistenten, brachte eine einzige getippte Frage den Chatbot dazu, seine internen Tools und deren Parameter aufzulisten, und lieferte einem Angreifer damit eine Karte möglicher Ziele. Alles in diesem Artikel stammt aus dieser Arbeit, damit Sie wissen, was Sie fragen sollten, bevor sich Ihr Agent mit seinem nächsten Server verbindet.
Was schützt MCP-Sicherheit?
MCP-Sicherheit schützt die Daten, Aktionen und Zugangsdaten, die Ihr Agent über jede Verbindung erhält. Im Kern ist MCP ein offener Standard, mit dem KI auf einheitliche Weise an externe Tools angebunden wird. Sobald Sie zum Beispiel einen Kalender-Server hinzufügen, kann Ihr Agent plötzlich Termine lesen, Einladungen versenden und mit dem Login des Kontos handeln.
Jeder neue MCP-Server kann Ihrem Agenten drei Arten von Zugriff verschaffen:
- Daten: Alles, was der Server lesen kann, von Kundendatensätzen bis zu internen Dokumenten
- Aktionen: Alles, was der Server den Agenten tun lässt, etwa Nachrichten senden, Datensätze bearbeiten oder Befehle ausführen
- Zugangsdaten: Die Passwörter und Zugriffsschlüssel, die der Server für andere Systeme vorhält
Wer einen Server kontrolliert oder Anweisungen in seine Antworten einschleust, kann über Ihren Agenten alle drei erreichen. Wie viel Zugriff ein Agent über alle seine Tools hinweg haben sollte, ist eine umfassendere Frage, die wir unter Agentic AI Sicherheit behandeln.
Welche MCP-Sicherheitsrisiken bringt jeder neue Server mit?
Die meisten MCP-Sicherheitsrisiken gehen auf einen Server zurück, dem Ihr Team ohne Prüfung vertraut hat. Das Open Worldwide Application Security Project (OWASP), eine gemeinnützige Organisation, deren Checklisten branchenweit genutzt werden, veröffentlicht inzwischen eine eigene Top 10 für MCP, noch im Beta-Stadium. Die meisten der folgenden Risiken stehen auf dieser Liste:
- Befehle, versteckt in Tool-Antworten: Ein Agent liest alles, was ein Server zurückschickt, ob Webseite, E-Mail oder Datenbankeintrag. Hat ein Angreifer Anweisungen in diesem Inhalt platziert, befolgt der Agent sie womöglich, als kämen sie von Ihnen. Dieser Angriff heißt indirekte Prompt-Injection, und Tool-Antworten sind einer seiner einfachsten Einfallswege.
- Server, die sich nach der Freigabe ändern: Ein Server kann am ersten Tag die Prüfung bestehen und später seine eigenen Anweisungen umschreiben. Der Abschnitt zu MCP Tool Poisoning weiter unten erklärt, wie dieser Trick funktioniert.
- Server, die jede Adresse abrufen: Viele Server laden für den Agenten Seiten herunter oder rufen andere Dienste auf. Ohne Prüfung des Ziels kann ein Angreifer den Agenten so lenken, dass der Server interne Systeme kontaktiert.
- Verbindungen mit zu vielen Rechten: Ein Server, der Dateien lesen soll, kann sie womöglich auch löschen oder anderswohin senden. Agenten nehmen den kürzesten Weg, den eine Verbindung zulässt, wie ein Entwickler erfuhr, als ein KI-Buchungsassistent die Reservierung eines anderen Mitglieds stornierte, um einen Platz in einem Fitnesskurs freizumachen.
- Unbekannte Server: Entwickler fügen manchmal eigenmächtig Server hinzu, ohne die Person zu informieren, die Tools freigibt. OWASP nennt sie Shadow-MCP-Server, und niemand kann eine Verbindung prüfen, von der er nichts weiß.
- Keine Aufzeichnung der Tool-Aufrufe: Ohne Logs kann später niemand nachvollziehen, was der Agent von einem Server verlangt hat und was zurückkam.
Wie eine eingeschleuste Anweisung zwischen Agenten wandert
Versteckte Befehle in Tool-Antworten sind schwerer nachzuverfolgen, wenn Agenten im Team arbeiten. Viele Produkte nutzen einen orchestrierenden Agenten, einen Koordinator, der eine Aufgabe aufteilt und jeden Teil an einen spezialisierten Subagenten übergibt. Der unabhängige Sicherheitsforscher Syed Anas Mohiuddin nennt den daraus entstehenden Angriff Protocol Pivoting. Die Kette läuft in drei Schritten ab:
- Ein Angreifer platziert Text in Inhalten, die ein MCP-Tool zurückgeben wird. Der Text ist so formuliert, dass er wie eine Aufgabenanfrage in dem Format aussieht, in dem Agenten miteinander kommunizieren.
- Der orchestrierende Agent liest die Antwort des Tools und gibt die Aufgabe weiter. Für den Orchestrator sieht die eingeschleuste Anfrage wie gewöhnliche Arbeit aus.
- Ein Subagent führt die Aufgabe aus. Da die Anfrage vom Orchestrator kommt, hat der Subagent keinen Grund zu hinterfragen, wo der Befehl seinen Ursprung hatte.
Im letzten Schritt kann kein Agent in der Kette mehr erkennen, dass ein Außenstehender die Anweisung geschrieben hat. Übergaben scheitern auch auf viele andere Arten, wie unser Beitrag zum Testen von Multi-Agenten-KI-Systemen zeigt.
MCP Tool Poisoning: Wenn ein vertrauenswürdiger Server seine Meinung ändert
MCP Tool Poisoning ist ein Angriff, der Anweisungen in den Beschreibungen eines Servers versteckt, also in den kurzen Hinweisen, die einem Agenten sagen, wann und wie er jede Funktion nutzen soll. Menschen lesen sie selten, doch die KI behandelt jede Zeile als Vorgabe. Vergiftete Hinweise können den Agenten deshalb zu Geheimnissen lenken oder das Verhalten anderer Tools verändern.
Eine der am schwersten zu erkennenden Varianten ist die verzögerte, bei der sich ein Server während der Prüfung korrekt verhält, die Freigabe erhält und erst dann seine eigenen Beschreibungen umschreibt. Am 10. August 2026 versuchte jemand genau das in großem Stil. In einer von der Firma Pillar Security gemeldeten Kampagne erreichten 23 Pull Requests, also vorgeschlagene Änderungen am Code eines Projekts, innerhalb von 74 Minuten 23 KI-Projekte auf GitHub. Jeder Vorschlag sollte denselben bösartigen MCP-Server hinzufügen.
Laut dem vierteljährlichen Exploit-Überblick von OWASP verhielt sich der Server bei seinen ersten drei Tool-Aufrufen normal. Nach dem dritten Aufruf schrieb er seine eigenen Tool-Beschreibungen um, um den verbundenen Agenten zu den wertvollsten Dateien auf dem Rechner eines Entwicklers zu lenken:
- SSH-Schlüssel, die den Zugang zu entfernten Servern öffnen
- Anmeldedaten für Cloud-Konten bei Amazon Web Services
- Den Verlauf der in den Rechner eingegebenen Befehle, der manchmal Passwörter enthält
- Die Konfigurationsdatei, die die Kubernetes-Servercluster eines Unternehmens steuert
Der Server öffnete diese Dateien nie direkt. Stattdessen nutzte er den vertrauenswürdigen Agenten, um sie einzusammeln, und versuchte, die Aktivität vor den Betreibern des Systems zu verbergen.
Keiner der Pull Requests wurde gemergt, und OWASP meldet keine bestätigte Kompromittierung. Dennoch kann ein Server, der eine Prüfung besteht, später feindselig werden. Als Schutz empfiehlt OWASP, die Tool-Beschreibungen jedes Servers bei der Freigabe festzuhalten und bei jeder Änderung eine neue Prüfung zu verlangen.
Warum Google und JPMorgan Chase denselben MCP-Fehler ausgeliefert haben
Viele MCP-Server rufen Webseiten ab oder sprechen andere Dienste unter jeder Adresse an, die der Agent liefert. Prüft der Server das Ziel nie, kann jeder, der den Agenten lenkt, Systeme erreichen, die privat bleiben sollten, etwa das interne Netzwerk eines Unternehmens. Diese Schwachstelle heißt Server-Side Request Forgery (SSRF).
2026 machten Google, JPMorgan Chase, Weaviate, Frankreichs Digitalagentur und eine indonesische Stadtverwaltung alle diesen Fehler, weil die Prüfung jeder ausgehenden Anfrage ein leicht übersprungener Schritt ist. Der Sicherheitsforscher Syed Anas Mohiuddin meldete ihn allen fünf Teams, die weder Code noch Eigentümer teilen, und alle haben ihn inzwischen behoben:
- Google: MCP Toolbox for Databases, mit hohem Schweregrad von 8,0 von 10 bewertet (CVE-2026-14540)
- JPMorgan Chase: Ein Open-Source-Server zur Suche in Dokumentation
- Weaviate: Der Connector des Datenbankunternehmens zu Google-Diensten
- DINUM (Frankreichs Digitalagentur): Der offizielle Server für die nationale Open-Data-Plattform des Landes
- Tangerang (eine indonesische Stadtverwaltung): Ein Server zur Sicherheitsüberwachung, der Schutz vor SSRF versprach, aber nur reine numerische Adressen blockierte
Laut TNW warteten im Oktober noch fünf weitere MCP-Server einer US-Bundesbehörde, darunter einer für Leistungsanträge bei Veterans Affairs, auf Korrekturen. Ein Abfluss von Daten wurde bisher nicht bestätigt.
Selbst bei einem Server einer bekannten Marke müssen die ausgehenden Anfragen getestet werden, bevor sich Ihr Agent darauf verlässt.
Was Sie prüfen sollten, bevor Ihr Agent einen MCP-Server nutzt
Gute MCP-Sicherheit bedeutet, jeden Server wie jeden anderen externen Code zu behandeln, auf den Ihr Produkt angewiesen ist. Was Sie prüfen können, hängt von der Quelle ab:
Wer einen Fehler behebt
Ihre Entwickler, nach Ihrem Zeitplan
Der ursprüngliche Autor, sofern das Projekt noch aktiv ist
Wie Änderungen zu Ihnen gelangen
Ihr eigener Release-Prozess
Automatische Updates, die womöglich ungelesen installiert werden
Was Sie einsehen können
Den gesamten Code und jede Tool-Beschreibung
Nur das, was der Autor veröffentlicht hat
Was typischerweise schiefgeht
Abkürzungen unter Termindruck, etwa ausgelassene Adressprüfungen
Versteckte Anweisungen oder Änderungen nach der Freigabe
Was zuerst getestet werden sollte
Die ausgehenden Anfragen des Servers und die Aktionen, die er erlaubt
Die Tool-Beschreibungen und Änderungen zwischen Versionen
In beiden Fällen sollte jede der folgenden Aussagen zutreffen, bevor Ihr Agent den Server nutzt:
- Sie wissen, wer den Server pflegt. Ein namentlich bekannter Verantwortlicher, aktuelle Updates und ein Weg, Probleme zu melden, sorgen dafür, dass Korrekturen Sie tatsächlich erreichen.
- Der Server erreicht nur die Adressen, die er braucht. Beim API-Testing sollten Anfragen an interne Systeme und unerwartete Ziele jedes Mal scheitern.
- Die Verbindung gewährt nur, was die Aufgabe erfordert. Ein Support-Agent, der Bestellungen nachschlägt, kann keine Erstattungen auslösen, und Lesezugriff ist überall dort Standard, wo es möglich ist.
- Der Server hat eigene, eng begrenzte Zugangsdaten. Seine Zugriffsschlüssel laufen schnell ab und öffnen nichts außerhalb seiner Aufgabe.
- Tool-Beschreibungen werden bei der Freigabe festgehalten. Jede spätere Änderung löst eine neue Prüfung aus, bevor der Agent den Server wieder nutzt.
- Tool-Antworten gelten als Information, nie als Befehl. Tester haben Anweisungen in Inhalte eingeschleust, die der Server zurückgibt, und bestätigt, dass der Agent sie ignoriert.
- Ein Mensch gibt riskante Aktionen frei. Der Agent kann keine Zahlungen leisten, keine Datensätze löschen und keinen Kunden schreiben, bis jemand aus Ihrem Team zustimmt.
- Jeder Tool-Aufruf wird protokolliert. Sie können im Nachhinein sehen, was der Agent angefragt hat und was zurückkam.
- Jemand außerhalb des Entwicklungsteams hat die Verbindung getestet. Entwickler bestätigen, dass ein Server funktioniert, während ein unabhängiger Tester prüft, wie er sich verhält, wenn jemand versucht, ihn zu knacken.
Wenn eine Verbindung an Kundendaten oder Geld heranreicht, wird diese Liste zum Ausgangsumfang für KI-Penetrationstests. Bei dieser Art von Test greifen Spezialisten den Agenten und seine Server so an, wie es ein echter Angreifer tun würde. Unsere Ingenieure erfassen jeden Server, den Ihr Agent aufrufen kann, testen jeden einzelnen gegen alle oben genannten Punkte und übergeben Ihrem Team einen Bericht darüber, was standhält und was vor dem Launch behoben werden muss.
Sie sind nicht sicher, wie sicher die Verbindungen Ihres Agenten sind? Sprechen Sie mit unserem Sicherheitsteam.
FAQ
Ist MCP sicher?
MCP-Sicherheit hängt von den Servern ab, die Sie hinzufügen, denn MCP selbst ist nur ein gemeinsamer Standard, mit dem KI-Agenten externe Tools nutzen. Das Protokoll prüft nicht, ob ein angebundenes Tool ehrlich oder gut gebaut ist. Diese Aufgabe liegt bei dem Team, das jede Verbindung freigibt, und deshalb ist ein Agent nur so sicher wie der am wenigsten getestete Server, auf den er sich verlässt.
Sollte ich MCP-Server von Drittanbietern verwenden?
Ja, sofern Sie einen MCP-Server eines Drittanbieters so prüfen, wie Sie einen neuen Softwarelieferanten prüfen würden. Achten Sie auf einen aktiven Maintainer, eine öffentliche Historie von Fehlerbehebungen und eine klare Dokumentation dessen, worauf er zugreifen kann. Vergeben Sie die kleinstmögliche Menge an Berechtigungen, mit der die Aufgabe noch erledigt wird, und überprüfen Sie die Konfiguration nach jedem Update, denn ein freigegebener Server kann sein Verhalten später ändern.
Wie sichert man einen MCP-Server ab?
Die Absicherung eines MCP-Servers erfordert mehrere Schutzschichten, und drei davon sind am wichtigsten. Beginnen Sie damit, den Zugriff zu begrenzen, sodass die Verbindung nur die Systeme und Aktionen erreicht, die ihre Aufgabe erfordert, und zwar mit Schlüsseln, die schnell ablaufen. Die Protokollierung jeder Anfrage und Antwort lässt Ihr Team dann genau sehen, was der KI-Agent getan hat. Die letzte Schicht ist ein externer Test, bei dem Spezialisten versuchen, versteckte Befehle in die Daten einzuschleusen, die der Server zurückgibt.
In unserer Sicherheitscode-Überprüfung einer in den USA ansässigen E-Commerce-Plattform werden Sicherheitslücken aufgezeigt und Lösungsansätze erläutert.
