Toxic Flows in MCP verstehen: das verborgene Risiko KI-nativer Systeme

Bei den meisten Diskussionen über KI-Sicherheit geht es nach wie vor um Prompts, Modelle und den direkten Datenzugriff. Diese Bereiche sind wichtig. Sobald ein KI-Agent jedoch Tools aufrufen, APIs nutzen und systemübergreifend agieren darf, verlagert sich das eigentliche Risiko. Es geht nicht mehr nur darum, was das Modell sehen kann, sondern darum, was der Agent tun kann, wenn er beginnt, Tools eigenständig zu kombinieren.

In diesem Zusammenhang gewinnt das Konzept eines Toxic Flow an Bedeutung.

Ein Toxic Flow ist eine Abfolge von Agentenaktionen, die eine Umgebung von angreifergesteuerten Anweisungen über sensible Daten bis hin zu einer Exfiltrationsstelle führt. Keiner der einzelnen Schritte muss böswillig sein. Jedes Tool kann genau das tun, wofür es entwickelt wurde. Die Gefahr liegt im durchgängigen Pfad, der entsteht, wenn Tools, Daten und Anweisungen unter der Kontrolle eines KI-Agenten kombiniert werden.

Das Model Context Protocol (MCP) verstärkt beide Seiten dieses Zusammenspiels. MCP standardisiert, wie Modelle und Agenten Verbindungen zu Tools, Repositories, Services und Datenquellen herstellen. Für Entwicklungsteams ist das ein klarer Vorteil: Sie erhalten eine einheitliche Möglichkeit, KI in alltägliche Workflows einzubinden – etwa zum Lesen von Issues, Aktualisieren von Tickets, Abfragen von Logs, Ändern von Code und Ausführen von Skripten. Gleichzeitig stellt MCP Agenten ein flexibles Toolkit zur Verfügung, mit dem sich leichter unbeabsichtigt Toxic Flows erzeugen lassen.

In einer herkömmlichen deterministischen Anwendung folgt eine bestimmte Eingabe einem festgelegten Codepfad. Entwickler können diese Pfade vollständig erfassen, testen und ihre Sicherheitseigenschaften bewerten. Ein MCP-basierter Agent verhält sich anders. Je nach natürlichsprachlichen Anweisungen, Kontext und Tool-Beschreibungen kann er aus vielen Tools auswählen und sie in unterschiedlicher Reihenfolge nutzen. Niemand schreibt jede mögliche Abfolge explizit vor. Das Modell wählt den Pfad zur Laufzeit.

Dieser Wandel schafft eine neue Angriffsfläche. Es reicht nicht mehr zu fragen, ob ein Modell Zugriff auf Geheimnisse oder private Repositories hat. Die wichtigere Frage lautet: Unter welchen Bedingungen entscheidet sich ein Agent dafür, sensible Daten durch eine Tool-Kette zu bewegen, die sie letztlich einer nicht vertrauenswürdigen Partei zugänglich macht?

„Toxic Flow“ bezeichnet diese Kette. Der Begriff macht deutlich, dass das Risiko erst im Zusammenspiel entsteht. Es ergibt sich daraus, wie Daten und Kontrolle durch viele Komponenten fließen – und nicht einfach aus einer einzelnen Fehlkonfiguration. In MCP-Umgebungen ist es entscheidend, diese Flows zu verstehen und zu steuern, denn Agenten sind bereits in wichtige Systeme eingebunden: Entwicklungsumgebungen, Quellcodeverwaltung, Workflows zur Reaktion auf Sicherheitsvorfälle und produktionsnahe Services.

Das tödliche Trio: Wie eine Tool-Kette zum Sicherheitsvorfall wird

Trotz des variablen Verhaltens von Agenten ist das Muster hinter Toxic Flows erstaunlich konsistent. Bei der Untersuchung realer Vorfälle treten in einer einzelnen Agentenausführung meist drei Elemente gemeinsam auf:

• angreifergesteuerte Anweisungen

• Zugriff auf sensible Daten

• eine Möglichkeit, diese Daten zu exfiltrieren

Wenn diese drei Bedingungen in einem Flow zusammentreffen, ist die Umgebung gefährdet – selbst wenn jedes beteiligte Tool aus einem legitimen Grund hinzugefügt wurde.

Nicht vertrauenswürdige Anweisungen sind oft der Ausgangspunkt. In einer MCP-Umgebung beschränken sie sich nicht auf Chat-Prompts. Ein Angreifer kann den Inhalt eines GitHub-Issues, eines Kunden-Support-Tickets, einer Nachricht in einem überwachten Chat-Kanal oder eines anderen Objekts beeinflussen, das der Agent lesen soll. Wenn der Agent diese Inhalte priorisieren, zusammenfassen oder darauf reagieren soll, hat sich der Angreifer einen Zugang zum Denkprozess des Agenten verschafft.

Sensible Daten befinden sich häufig hinter Tools, die zur Produktivitätssteigerung eingeführt wurden. Dazu gehören etwa Aktionen wie das Lesen von Repository-Inhalten, Abrufen von Konfigurationsdateien, Abfragen von Issue-Trackern, Herunterladen von Logs oder Zugriff auf interne Datensätze. Entwickler möchten, dass der Agent dieselben Informationen sieht, die sie zur Fehlerbehebung oder zum Verständnis eines Produktionsproblems benötigen. Daher umfasst das Toolset eines Agenten oft direkten Zugriff auf besonders wertvolle Daten.

Exfiltrationsziele sind Tools oder Kanäle, über die Daten die sichere Grenze verlassen können. Gängige Beispiele sind HTTP-Clients, die beliebige URLs aufrufen können, Konnektoren zum Schreiben in Drittanbietersysteme, Integrationen zum Versenden von E-Mails oder Chat-Nachrichten und in manchen Fällen die Antwort des Modells selbst, wenn der Aufrufer nicht vertrauenswürdig ist. Teams fügen solche Funktionen oft nach und nach hinzu, wenn sie ihre Agenten mit weiteren Workflows verbinden.

Ein einfaches MCP-Szenario veranschaulicht, wie das tödliche Trio zusammenkommt. Stellen Sie sich einen mit GitHub verbundenen MCP-Server vor, der einen Entwicklungsassistenten unterstützt. Der Assistent liest Issues aus einem Repository, ruft mithilfe von MCP-Tools relevante Dateien und Konfigurationsdetails ab und erstellt hilfreiche Zusammenfassungen für die Verantwortlichen. Für Integrationstests ist außerdem ein HTTP-Tool verfügbar, das Anfragen an beliebige Endpunkte senden kann.

Ein Angreifer eröffnet in diesem Repository ein Issue mit detaillierten Anweisungen. Darin heißt es, ein komplexer Fehler lasse sich nur diagnostizieren, wenn Umgebungsdateien und Konfigurationsdaten aus der Codebasis gesammelt und anschließend als JSON-Payload an eine bestimmte URL gesendet werden, damit ein externes Analysesystem sie prüfen kann. Aus Sicht des Agenten wirkt das wie eine gründliche und nachvollziehbare Anfrage.

Folgt der Agent dieser Anleitung, liest er das Issue (nicht vertrauenswürdige Anweisungen), durchsucht das Repository nach Konfigurations- und Umgebungsdateien (sensible Daten) und ruft das HTTP-Tool auf, um diese Informationen an die URL des Angreifers zu übertragen (Exfiltrationsziel). Kein einzelnes Tool ist auf offensichtliche Weise falsch konfiguriert. Der Sicherheitsvorfall entsteht dadurch, wie diese Tools unter der Kontrolle des Modells kombiniert werden.

Herkömmliche KI-Sicherheitsmaßnahmen tun sich mit diesem Muster schwer. Prompt-Filter und LLM-Firewalls prüfen einzelne Prompts und Antworten. Sie haben kaum Einblick in die dazwischenliegenden Tool-Aufrufe und Datenbewegungen, die diese Prompts mit externen Systemen verbinden. Code-Scanning prüft die Implementierung von Tools, nicht deren Kombination zur Laufzeit. Zugriffsprüfungen bestätigen, dass jedes Tool einen legitimen Zweck erfüllt. Sie untersuchen jedoch selten, ob nicht vertrauenswürdige Inhalte eine Abfolge auslösen können, die diese Tools zu einem Toxic Flow verbindet.

Dadurch entsteht eine Lücke. Unternehmen glauben womöglich, ihre Prompts, Modelle und Tools seien abgesichert, während das eigentliche Risiko in den dynamischen Aktionsketten liegt, die über MCP orchestriert werden. Wenn Sie diese Lücke als „tödliches Trio“ betrachten, rückt das eigentliche Problem in den Fokus: Sobald angreifergesteuerte Anweisungen, sensible Daten und ein Exfiltrationspfad innerhalb eines Flows erreichbar sind, ist die Umgebung gefährdet – unabhängig davon, wie sorgfältig jede einzelne Komponente eingeführt wurde.

Warum die meisten KI-Sicherheitsansätze Toxic Flows übersehen

Sobald das tödliche Trio verstanden ist, wird deutlich, dass viele aktuelle KI-Sicherheitsansätze auf eine andere Art von Problemen zugeschnitten sind. Sie konzentrieren sich darauf, was das Modell sieht und sagt, statt darauf, was der Agent über vernetzte Systeme hinweg tut.

Prompt-Kontrollen, Inhaltsfilter und LLM-Firewalls gehören meist zu den ersten Schutzmaßnahmen, die Unternehmen einführen. Diese Systeme prüfen Ein- und Ausgaben auf Richtlinienverstöße oder sensible Begriffe. Sie können offensichtlichen Missbrauch verringern und bestimmte Arten von Prompt-Injection verhindern. Toxic Flows laufen jedoch oft in einer Reihe von Schritten ab, die für sich genommen völlig legitim erscheinen. Im GitHub-Beispiel scheint der Assistent einer detaillierten Anfrage zur Fehlerbehebung nachzukommen. Die endgültige Antwort lässt nicht unbedingt erkennen, dass Geheimnisse über dazwischenliegende Tool-Aufrufe exfiltriert wurden.

Auch herkömmliche Anwendungssicherheitstools sind auf statische Artefakte und deterministische Pfade ausgerichtet. Statische Analyse, Software Composition Analysis und Infrastructure-as-Code-Scanning eignen sich für Umgebungen, in denen Code und Konfiguration jede zulässige Aktion definieren. Sie können prüfen, ob MCP-Tools sicher implementiert sind, Abhängigkeiten aktuell sind und Zugriffstoken korrekt verwaltet werden. Was sie nicht ohne Weiteres erfassen können, ist die Entscheidung eines Agenten, diese Tools aufgrund natürlichsprachlicher Eingaben auf unerwartete Weise zu verknüpfen.

Laufzeit-Logging und -Monitoring bieten eine weitere Schutzebene, sind in diesem Zusammenhang jedoch ebenfalls eingeschränkt. Entwickler können Traces von Tool-Aufrufen, Antworten und Fehlern sammeln und einzelne Vorfälle untersuchen. Die Herausforderung ist kombinatorischer Natur: Die Zahl möglicher Flows steigt drastisch, wenn über MCP weitere Tools und Systeme miteinander verbunden werden. Sich bei der Erkennung gefährlicher Muster auf manuelle Prüfungen zu verlassen, ist kaum praktikabel – insbesondere, wenn sich das Verhalten des Agenten schon durch kleine Änderungen an der Eingabe oder am Kontext verschieben kann.

Selbst neuere KI-spezifische Sicherheitslösungen konzentrieren sich häufig auf lokale Prüfungen. Sie können Parameterbeschränkungen für ein bestimmtes Tool durchsetzen oder den Zugriff eines bestimmten Agenten auf bestimmte Geheimnisse einschränken. Diese Kontrollen bleiben auf einzelne Komponenten ausgerichtet. Sie analysieren in der Regel keine vollständigen Pfade, die bei nicht vertrauenswürdigen Inhalten beginnen und damit enden, dass Daten die Vertrauensgrenze verlassen.

Die Folge ist eine Abdeckungslücke: Investitionen in die Modellsicherheit, Prompt-Validierung und die Sicherheit einzelner Tools erstrecken sich nicht automatisch auf den Interaktionsraum, der durch MCP entsteht. Werden die Komponenten einzeln betrachtet, scheint die Umgebung womöglich gut kontrolliert. Zusammen ermöglichen sie dennoch Toxic Flows.

Um dieses Problem anzugehen, müssen Sicherheitsteams eine andere Frage stellen: Gibt es in der Umgebung einen Pfad, über den angreifergesteuerte Anweisungen sensible Daten zu einem Exfiltrationsziel leiten können? Toxic Flow Analysis liefert eine strukturierte Antwort.

Toxic Flow Analysis im Überblick

Toxic Flow Analysis (TFA) bietet eine graphbasierte Perspektive auf KI-gestützte Systeme. Anstatt Prompts oder Tools isoliert zu betrachten, bildet die Lösung ab, wie Agenten, MCP-Server, Tools und zugrunde liegende Systeme miteinander verbunden sind. Anschließend sucht sie nach Pfaden, auf denen sich das tödliche Trio verwirklichen kann.

Am Anfang steht die Darstellung der Umgebung. Im MCP-Kontext umfasst sie MCP-Server, deren Tool-Manifeste, Modell- und Agentenkonfigurationen sowie die externen Systeme, auf die diese Tools zugreifen – etwa Quellcodeverwaltung, Ticketing-Plattformen, Messaging-Systeme und allgemeine HTTP-Endpunkte. Aus diesen Informationen erstellt TFA einen Flow-Graphen, der erfasst, welche Komponenten welche Tools aufrufen können, worauf diese Tools zugreifen können und wohin sie ihre Ausgaben senden können.

Anschließend wird dieser Graph um sicherheitsrelevante Attribute ergänzt. Knoten und Kanten werden mit Kennzeichnungen versehen, die angeben, ob nicht vertrauenswürdige Parteien die zugrunde liegenden Anweisungen beeinflussen können, ob die verarbeiteten Daten sensibel sind und ob der jeweilige Schritt eine Vertrauensgrenze überschreitet. So lassen sich gewöhnliche interne Flows von solchen unterscheiden, die angreifergesteuerte Angriffsflächen mit besonders wertvollen Assets und anschließend mit externen Zielen verbinden.

Mit einem annotierten Graphen kann TFA systematisch nach Pfaden suchen, auf denen alle drei Bedingungen des tödlichen Trios erfüllt sind. Die Lösung erkennt Abfolgen, in denen nicht vertrauenswürdige Anweisungen einen Agenten erreichen können, dieser Agent über einen Pfad zu Tools mit Zugriff auf sensible Daten verfügt und derselbe Kontext ein Exfiltrationsziel umfasst. Solche Toxic Flows bilden realistische Angriffspfade für entschlossene Angreifer, die natürlichsprachliche Eingaben und vorhandene Integrationen statt eigens entwickelter Malware nutzen.

Erkennung allein reicht nicht aus. Damit TFA im Betrieb einen praktischen Nutzen hat, muss die Lösung auch Priorisierung und Maßnahmen unterstützen. Nicht jeder potenzielle Flow birgt dasselbe Risiko. Ein Pfad, über den Produktionsgeheimnisse an einen beliebigen externen Endpunkt gelangen können, hat ein anderes Auswirkungsprofil als ein Pfad, über den nicht sensible Metadaten an ein kontrolliertes internes System gelangen könnten. Toxic Flow Analysis kann anhand von Faktoren wie Datenklassifizierung, Ausnutzbarkeit, Reichweite des Zugriffs und Art des Exfiltrationsziels Auswirkungswerte vergeben. So können Teams ihre Maßnahmen gezielt priorisieren.

Diese graphenbasierte Perspektive ermöglicht es Security- und Plattformteams, Fragen zu beantworten, die sich sonst nur schwer klären lassen: Welche MCP-Server stellen Kombinationen von Tools bereit, die toxische Datenflüsse erzeugen können? Welche Agents sind gleichzeitig mit nicht vertrauenswürdigen Anweisungsquellen und Exfiltrationszielen verbunden? Wie verändert ein neues Tool, etwa ein generischer HTTP-Client, die möglichen Datenflüsse?

Wichtig ist: TFA ist keine einmalige Maßnahme. Wenn sich Agents weiterentwickeln, MCP-Konfigurationen ändern und neue Tools hinzukommen, muss der Datenflussgraph aktualisiert und neu bewertet werden. Als kontinuierliche Fähigkeit wird Toxic Flow Analysis zur Grundlage eines ausgereifteren Ansatzes für Risiken in KI-nativen Umgebungen: eines Ansatzes, der das Verhalten der gesamten Umgebung versteht und nicht nur die Konfiguration ihrer einzelnen Komponenten.

Damit ist der nächste Schritt klar: Sobald ein Unternehmen toxische Datenflüsse erkennen und bewerten kann, muss es entscheiden, wie deren Ausführung in der Praxis verhindert werden soll. In einer Umgebung, in der Agents bereits eigenständig handeln können, reicht Transparenz ohne Kontrolle nicht aus.

Warum MCP-Umgebungen Leitplanken statt bloßer Transparenz brauchen

Toxic Flow Analysis zeigt, wo KI-native Risiken liegen. Erkenntnisse allein verhindern jedoch keine Vorfälle. Kann ein System feststellen, dass eine bestimmte Kombination aus Agent, MCP-Server und Tool einen toxischen Datenfluss erzeugen kann, braucht es dennoch einen Mechanismus, der eingreift, wenn dieser Datenfluss ausgeführt werden soll.

MCP macht diese Anforderung dringlicher, weil es heterogene Systeme über ein einziges Protokoll verbindet. Über MCP kann ein Agent auf Quellcodeverwaltung, Build-Pipelines, Monitoring-Systeme, Kollaborationsplattformen und interne Services zugreifen. Die einzelnen Integrationen werden von unterschiedlichen Teams und Anbietern verwaltet. In den zugrunde liegenden Systemen gibt es normalerweise keinen zentralen Punkt, an dem sich eine einzelne Richtlinie für alle beteiligten Datenflüsse durchsetzen lässt.

Am praktikabelsten lassen sich Richtlinien direkt in der KI-Ebene durchsetzen: auf Ebene der MCP-Server, der von ihnen bereitgestellten Agents und der Orchestrierungslogik, die festlegt, welche Tools verfügbar sind und wie sie genutzt werden dürfen. Leitplanken sind in diesem Kontext konkrete Durchsetzungsmechanismen. Sie können geplante oder laufende Handlungsabläufe prüfen, mit den Erkenntnissen aus Toxic Flow Analysis und den geltenden Richtlinien abgleichen und diese Abläufe anschließend zulassen, ändern oder blockieren.

Damit Leitplanken wirksam sind, brauchen sie Kontext. Der aktuelle Prompt oder ein einzelner Tool-Aufruf reicht nicht aus. Sie müssen wissen, welcher Agent läuft, welche Tools in der Umgebung verfügbar sind, wie diese konfiguriert sind und auf welche Daten und externen Systeme sie zugreifen. Hier spielen AI-BOM und MCP-Scanning eine entscheidende Rolle.

Die AI-BOM liefert eine strukturierte Beschreibung des KI-Stacks: Modelle, Datensätze, Frameworks, MCP-Server und wichtige Integrationen. Das MCP-Scanning erstellt eine praxisnahe Bestandsaufnahme der tatsächlichen Installationen auf Entwickler- und Administrator-Endgeräten: welche MCP-Server installiert sind, welche Tools sie bereitstellen und wie sie konfiguriert sind. Zusammen ermöglichen diese Fähigkeiten einer Orchestrierungsebene, die Erkenntnisse aus TFA mit konkreten Ausführungskontexten abzugleichen.

Auf dieser Grundlage lassen sich Leitplanken präzise einsetzen. Erkennt Toxic Flow Analysis, dass eine bestimmte Kombination aus Agent und MCP-Konfiguration es ermöglichen würde, dass nicht vertrauenswürdige GitHub-Issues Geheimnisse an einen externen HTTP-Endpunkt weitergeben, kann eine Richtlinie genau diese Kombination verhindern, während andere Datenflüsse unbeeinträchtigt bleiben. So sind keine weitreichenden, pauschalen Einschränkungen nötig, die den Nutzen von Agents schmälern.

Ohne eine solche integrierte Durchsetzung droht Unternehmen, ein bekanntes Muster zu wiederholen: aussagekräftige Dashboards und wertvolle Erkenntnisse, aber kaum Auswirkungen auf das Verhalten im Alltag. Leitplanken schließen die Lücke zwischen Analyse und Aktion und sorgen dafür, dass das Bewusstsein für toxische Datenflüsse zu konkreten Einschränkungen dessen führt, was Agents tun dürfen.

Von der Analyse zur Kontrolle: Leitplanken in der Praxis und die Bedeutung einheitlicher Governance

Um Erkenntnisse zu toxischen Datenflüssen in wirksame MCP-Leitplanken umzusetzen, braucht es Richtlinien, Orchestrierung und die Abstimmung mit vorhandenen Tools.

Richtlinien bilden den Ausgangspunkt. Security-, Plattform- und Entwicklungsteams einigen sich auf Grenzen, die nicht überschritten werden dürfen. Beispiele sind das Verbot von Datenflüssen, bei denen Agents mit Zugriff auf externe Tickets Produktionsgeheimnisse abrufen und Daten an beliebige URLs senden können, oder zusätzliche Kontrollen für Datenflüsse mit regulierten Daten. Toxic Flow Analysis liefert die nötigen Belege, um diese Richtlinien festzulegen und zu begründen.

Anschließend prüft eine Orchestrierungsebene das Verhalten der Agents anhand dieser Richtlinien. Wenn ein Agent über MCP eine Abfolge von Tool-Aufrufen ausführen will, die einen toxischen Datenfluss abschließen würde, kann die Leitplanke eingreifen. Sie kann die Abfolge blockieren, eine zusätzliche Genehmigung anfordern oder die Anfrage über einen sichereren Ablauf leiten. Die Durchsetzung erfolgt nahe am Entscheidungspunkt des Agents, wo der vollständige Kontext des Datenflusses sichtbar ist.

Um diesen Ansatz zu skalieren, brauchen Unternehmen eine Governance-Ebene, die ihr Ökosystem koordiniert. AI-BOM und MCP-Scanning liefern dieser Ebene aktuelle, präzise Informationen über zentral verwaltete und lokal installierte MCP-Umgebungen. So kann die Governance-Ebene einheitliche Leitplanken durchsetzen – unabhängig davon, ob ein Agent auf einer gemeinsam genutzten Plattform oder auf dem Rechner eines Entwicklers läuft.

Die Behebung vor Ort bleibt unverzichtbar. Ziel ist es nicht, CI/CD-Systeme, IDE-Assistenten, Ticketing-Plattformen oder Data-Governance-Tools zu ersetzen, sondern sicherzustellen, dass sie auf Grundlage eines gemeinsamen Risikoverständnisses handeln. Wenn TFA einen neuen toxischen Datenfluss aufdeckt, kann die Orchestrierungsplattform Issues erstellen, Konfigurationsänderungen vorschlagen oder Zugriffsregeln in den Systemen aktualisieren, die Teams bereits verwenden. Die Governance-Ebene wird zum Koordinationspunkt; vorhandene Tools bleiben die Ausführungsinstanzen für Änderungen.

Mit zunehmender Nutzung können Unternehmen dank dieser Funktionen von experimentellen Kontrollen zu einem kohärenten KI-Sicherheitsprogramm übergehen. Sie können mit Transparenz durch Toxic Flow Analysis beginnen, gezielte Leitplanken für ihre risikoreichsten Datenflüsse hinzufügen und diese mit der Zeit ausweiten. AI-BOM und MCP-Scanning sorgen dabei dafür, dass die Richtlinien stets dem tatsächlichen Zustand der Umgebung entsprechen.

MCP dürfte zu einem zentralen Baustein KI-nativer Systeme werden. Toxic Flow Analysis in Verbindung mit Leitplanken, die auf präzisen Bestandsaufnahmen und einer einheitlichen Governance beruhen, bietet die Möglichkeit, die Vorteile von MCP zu nutzen und zugleich die folgenschwersten Risiken unter Kontrolle zu halten. Mit der Weiterentwicklung dieser Fähigkeiten wird der nächste Schritt deutlich: Unternehmen brauchen praktikable Wege, solche Analysen in die Praxis umzusetzen.

Möchten Sie mehr erfahren? Entdecken Sie, wie Snyk den Schutz KI-nativer Systeme voranbringt, und probieren Sie Snyk MCP Scan noch heute aus.