Wie weitreichend die neue Handlungsfähigkeit ist, zeigt Cutolo an einem Alltagsbeispiel: Bittet ein Nutzer seinen KI-Assistenten – etwa Claude oder ChatGPT – einen Termin zu vereinbaren, kann das Modell über einen Google-Calendar-MCP-Connector die Verfügbarkeit prüfen, einen Kalendereintrag anlegen und eine Erinnerung setzen, ohne dass der Nutzer manuell eingreifen muss. Dabei wählt das Modell selbst die Funktionen aus, die ein MCP-Server bereitstellt – etwa “E-Mails abrufen”, “Kalendereintrag erstellen” oder “Dateien durchsuchen” – und bestimmt auch die Parameter, mit denen diese aufgerufen werden.
Das zentrale Problem: LLMs können nicht zwischen Inhalt und Anweisung unterscheiden. Holt ein MCP-Connector Inhalte aus einer externen Quelle wie einer E-Mail oder einem Dokument, verarbeitet das Modell alles gleichermaßen als Eingabe. Für Angreifer ist es damit trivial, eine schädliche Anweisung in Inhalten zu verstecken, die das Modell abruft.
Cutolo veranschaulicht das mit einer indirekten Prompt-Injection: Ein Angreifer sendet dem Opfer eine E-Mail, die neben legitimem Text auch versteckte Schadanweisungen enthält. Bittet der Nutzer seinen Assistenten, die E-Mail zusammenzufassen, lädt der Connector den gesamten Inhalt in den Kontext des Modells – und das LLM führt die verborgene Anweisung aus, etwa das Abfließen von Dateien und Daten oder das Versenden von E-Mails im Namen des Nutzers, ohne dass dieser etwas davon mitbekommt. In Umgebungen mit mehreren Connectoren zu lokalen Dateien, Jira-Tickets, Google Drives und Festplattenordnern könne eine einzige präparierte E-Mail koordinierte Aktionen über all diese Dienste in einem einzigen Durchlauf auslösen.
Eine zweite Angriffsklasse ist das Tool Poisoning. Verbindet sich ein LLM mit einem MCP-Server, fragt es dort die Liste aller unterstützten Werkzeuge ab – samt Namen, Beschreibungen und Eingabeanforderungen. Diese Metadaten landen direkt im Kontextfenster des Modells. Ein Angreifer kann darin schädliche Anweisungen platzieren, die das LLM wiederum als Inhalt verarbeitet.
Als dritte Klasse nennt Cutolo den Rug Pull: Der Betreiber eines MCP-Servers – oder ein Angreifer, der Zugriff erlangt hat – verändert den Server böswillig. Das Protokoll besitzt derzeit keinen Mechanismus, um einen MCP-Client oder KI-Agenten über Änderungen am Server zu informieren. Ein zunächst legitimer Server kann so nach einem manipulierten Update schädliche Werkzeugbeschreibungen ausliefern, ohne dass Agent oder Client die Manipulation erkennen können.
Weil es sich um grundlegende Eigenschaften der Funktionsweise von LLM und MCP handelt, lasse sich das Risiko nicht durch Updates beseitigen, betont Cutolo. Gegen die indirekte Prompt-Injection empfiehlt er, MCP-Server für private und öffentliche Daten zu trennen, jeden verarbeiteten Kontext auf anweisungsartige Muster, versteckten Text und ungewöhnliche Formatierung zu prüfen und bei allen sensiblen Aktionen Menschen einzubeziehen. Zudem sollten Organisationen jeden MCP-Server inventarisieren und prüfen, das Least-Privilege-Prinzip durchsetzen, sämtlichen MCP-Verkehr protokollieren und Verhaltensbasislinien aufbauen, die Abweichungen melden. Gegen Tool Poisoning helfe es, die Tool-Metadaten vor der Installation eines Servers auf schädliche Anweisungen zu durchsuchen.