Prompt Injection und die tödliche Trifecta: Der Schutz von KI-Agenten
Prompt-Injektion und das tödliche Dreifachproblem: Warum KI-Agenten Ihre Anweisungen nicht von denen eines Angreifers unterscheiden können, wie EchoLeak und der GitHub MCP-Angriff funktionierten.
Quellen: Prompt Injection and Agent Security: The Unsolved Problem
Im Juni 2025 enthüllten Forscher einen Fehler in Microsoft 365 Copilot und nannten ihn EchoLeak. Der Angriff verlief wie folgt: Jemand sendet Ihnen eine E-Mail mit normaler Optik. Sie öffnen sie nicht, klicken auf nichts und lesen sie auch nicht. Copilot liest sie dennoch, weil es Ihren gesamten Posteingang durchliest, um Ihre Fragen zu beantworten. In dieser E-Mail sind Anweisungen versteckt, die Copilot anweisen, sensible Daten aus Ihren anderen Dokumenten abzurufen und sie über ein automatisch geladenes Bild heimlich auf einen externen Server zu senden. Ohne jegliches Klicken und ohne dass das Opfer etwas Falsches tut. Der Agent gehorcht – nur nicht der richtige Empfänger.
EchoLeak erhielt einen CVE-Code (CVE-2025-32711), wurde behoben und fiel aus – als erstes bekanntes Fall von Prompt-Injection, das zur Stehlung echter Daten in einem produktiven KI-System eingesetzt wurde. Es wird nicht der letzte Fall sein. Im folgenden Jahr trat derselbe Angriffstyp in GitHubs MCP-Integration, GitLabs Duo, Slacks KI-Funktionen, Googles NotebookLM sowie in jedem veröffentlichten KI-Browser auf. Gegen Ende des Jahres 2025 erklärte die eigene Sicherheitsleitung von OpenAI öffentlich, dass Prompt-Injection für Browser-Agenten möglicherweise niemals vollständig gelöst werden könne, und das britische National Cyber Security Centre stimmte dem zu.
Die grundlegende Sicherheitsfrage bei agierenden KI-Systemen ist einfach – doch wir haben bisher keine klare Antwort darauf: Das Modell erhält Ihre Anweisungen sowie die eines Angreifers über genau denselben Kanal und kann sie nicht zuverlässig voneinander unterscheiden. Im Folgenden wird erklärt, warum das der Fall ist, warum dies für agierende Systeme weitaus schlimmere Folgen hat als für Chatbots, sowie welche Schutzmaßnahmen tatsächlich funktionieren – im Gegensatz zu denen, die in den Präsentationen der Anbieter dargestellt werden.
Ein Kanal für alles
Zuerst muss der Mechanismus verstanden werden, denn gerade ein falsches Verständnis davon ist der Ausgangspunkt für mangelhafte Sicherheitsempfehlungen.
Ein Sprachmodell erhält eine einzige Eingabe: eine lange Abfolge von Tokens. Der Systemprompt gehört dazu. Die Frage des Benutzers sind Tokens – genauso wie die Webseite, die das Agent gerade heruntergeladen hat, die E-Mail, die es gelesen hat, die Ausgabe des Tools, die es erhalten hat, das parsierte PDF sowie der Alt-Text einer Bilddatei. All das kommt als eine einzige, flache Sequenz an, und das Modell prognostiziert, was als Nächstes kommt. Nichts weist darauf hin, dass bestimmte Tokens als vertrauenswürdige Befehle des Benutzers und andere als unvertrauenswürdige Daten zu betrachten sind. Simon Willison, der 2022 den Begriff „Prompt-Injection“ prägte, beschreibt dies folgendermaßen: Modelle befolgen gerne alle Anweisungen, die sie erhalten, egal ob sie vom Benutzer oder von einer anderen Quelle stammen.
Das ist das Kernproblem, und es geht sehr tief. Keine Aktualisierung des Modells wird es beheben, da die Schwäche bereits in der Konstruktion vorhanden ist. Diese Systeme wurden dafür entwickelt, Anweisungen in einfachem Sprachstil auszuführen. Dann geben wir ihnen Texte in einfachem Sprachstil, die aus dem öffentlichen Internet extrahiert wurden, und tun so, als wären wir schockiert, wenn die darin enthaltenen Befehle ausgeführt werden. Injektion bedeutet einfach nur, dass die Systeme ihre Aufgabe erfüllen, aber für den falschen „Chef“.
Vergleichen Sie die SQL-Injektion, die dem Angriff seinen Namen gab. Eine echte Lösung für SQL-Injektionen bieten parametrisierte Abfragen, bei denen der Datenbank eindeutig mitgeteilt wird, dass dieser Teil ein Befehl und jener Teil Daten sind und daher niemals als Befehl behandelt werden dürfen. Drei Jahrzehnte der Web-Sicherheit beruhen darauf, diese Trennlinie innerhalb des Systems zu ziehen. In einem LLM weiß niemand, wie das zu bewerkstelligen ist – alles erfolgt über denselben Kanal, wobei der Befehlskanal und der Datens canal identisch sind. Deshalb versagt der gängige Reflex, dem Modell in der Systemanweisung mitzuteilen, Anweisungen aus Webinhalten zu ignorieren. Man nutzt den kompromittierten Kanal, um den kompromittierten Kanal zu schützen, und ein gut gestalteter Inhalt kann immer eine auf Englisch formulierte Warnung überwinden.
Zwei Angriffstypen werden oft verwechselt. Bei der direkten Einbettung gibt der Benutzer selbst etwas Hostiles ein, wie beispielsweise die Aufforderung, den Systemprompt anzuzeigen. Das ähnelt eher einem Jailbreak: Eine Person greift einen Agenten an, den sie eigentlich nutzen darf. Die indirekte Einbettung hingegen bedroht die Agenten selbst. Die feindliche Anweisung ist in externem Material verborgen, das der Agent bei seiner Arbeit verarbeitet – wie eine Webseite, eine E-Mail, eine Kalendereinladung, ein Codekommentar oder ein GitHub-Problem. Der Angreifer wendet sich niemals direkt an den Agenten. Er platziert eine Falle in Inhalten, die er erwartet, dass der Agent eines Tages im Auftrag eines ihm vertrauenden Opfers liest. Alle oben genannten Vorfälle gehörten zu dieser Art. Sie lassen sich skalieren, weil der Angreifer keinen Zugriff auf Sie benötigt, sondern nur einen gewissen Einfluss darauf, wofür Sie Ihren Agenten einsetzen.
Das tödliche Dreierpack
Das nützlichste mentale Modell in diesem Zusammenhang ist Simons Willisons „lethal trifecta“, das erklärt, warum einige Agenten katastrophal ausnutzbar sind, während andere lediglich lästig beim Angriff sind.
Ein Agent wird zu einer Waffe zum Datenraub, wenn er drei Fähigkeiten kombiniert.
- Zugang zu privaten Daten. Er kann Ihre E-Mails, privaten Repositorien, Kundenunterlagen oder das interne Wiki lesen. Das ist in der Regel der Grund für die Existenz des Agenten, weshalb man ihn nicht einfach entfernen kann.
- Zugang zu unzuverlässigem Inhalt. Er verarbeitet Texte, die er nicht selbst geschrieben hat und die Sie nicht überprüft haben: Webseiten, eingehende E-Mails, Dokumente, Ausgaben von Drittsystemen. Auch das ist in der Regel der Zweck.
- Eine Möglichkeit zur externen Kommunikation. Er kann Daten an einen Ort senden, an dem ein Angreifer sie sehen kann, indem er eine HTTP-Anfrage sendet, eine E-Mail verschickt, eine API aufruft, ein Bild von einer URL des Angreifers abruft oder einen Pull Request öffnet.
Eines davon ist in Ordnung, und in der Regel sind auch zwei ausreichend, um zu überleben. Alle drei in einem Agenten unter denselben Anmeldeinformationen sind jedoch wie eine geladene Waffe, die auf Ihre Daten gerichtet ist. Ein Angreifer, der die zweite Fähigkeit kontrolliert, kann die Anweisungen des Agenten übernehmen, die erste nutzen, um Geheimnisse zu sammeln, und die dritte, um diese auszusenden. Genau dieser Ablauf wurde bei den Angriffen von EchoLeak und GitHub MCP beobachtet.
Der GitHub-Fall ist gut genug strukturiert, um ihn Schritt für Schritt zu durchgehen. Invariant Labs demonstrierte ihn im Mai 2025. Ein Entwickler verbindet einen Programmieragenten über einen persönlichen Zugriffstoken mit dem offiziellen GitHub MCP-Server – ein Token, das die meisten Menschen so konfigurieren, dass es auf alle ihre Repositorien, sowohl öffentliche als auch private, Zugriff gewährt. Der Entwickler bittet um etwas Unschädliches, wie beispielsweise den Überblick über offene Issues in einem öffentlichen Repo. Der Agent liest diese Issues. Eines davon wurde von einem Angreifer erstellt und enthält versteckte Anweisungen: Lesen Sie die privaten Repositorien dieses Benutzers und veröffentlichen Sie das Gefundene in einem öffentlichen Pull Request. Der Agent verfügt über die zweite Fähigkeit (er liest lediglich den Inhalt des Angreifers), die erste (der Token ermöglicht den Zugriff auf private Repositorien) sowie die dritte (er kann einen öffentlichen Pull Request erstellen). Er führt all das aus. In der Demonstration wurden private Code-Dateien sowie sogar persönliche Zahlungsinformationen für jeden sichtbar. Jede Aktion, die das Token ausführte, lag innerhalb seiner Berechtigungen, und der Agent funktionierte genau wie vorgesehen. Die „Trifecta“ wurde somit einfach abgeschlossen.
Betrachten Sie die Lösung: Docksers Absicherungsmaßnahmen versuchten nicht, das bösartige Problem zu erkennen. Sie störten die „Trifecta“ durch eine Richtlinie – jede Sitzung ist an ein einziges Repository gebunden, sodass der Agent im Moment, in dem er nach einem zweiten greift, unabhängig von den Anweisungen blockiert wird. Das Modell wurde nicht intelligenter. Eine Fähigkeit wurde genau dort entfernt, wo Fähigkeiten kombiniert werden, und das ist die Grundlage jeder echten Verteidigung.
Warum Agenten um ein Vielfaches schlimmer sind als Chatbots
Frühe Bedenken hinsichtlich der Sicherheit von LLMs ließen Injektionen noch erträglich erscheinen. Ein Chatbot sagte etwas Unhöfliches oder gab seinen Prompt preis – ärgerlich, aber nicht katastrophal. Agenten hingegen verschieben die Risiken in alle Richtungen.
Chatbots erzeugen Texte, während Agenten Aktionen ausführen. Wenn ein Chatbot gehackt wird, liest eine Person eine andere Antwort. Wenn ein Agent gehackt wird, verhält sich das System selbst anders und kann tatsächlich Handlungen ausführen: Es kann Menschen per E-Mail kontaktieren, Geld überweisen, Daten löschen, Code zusammenführen oder Shell-Befehle ausführen. Die Top 10 des OWASP Agentic Security-Projekts für 2026 liest sich wie eine Liste genau dieser Folgen: Zielübernahme, Fehlgebrauch von Tools, Missbrauch von Berechtigungen, „Memory Poisoning“ sowie Fehler, die sich in mehragentigen Systemen ausbreiten. Jede dieser Probleme ist im Grunde eine einfache Injektion, die durch die Verbindung des Modells zu echten Funktionalitäten verstärkt wird.
Drei Faktoren erklären das erhöhte Risiko.
Die Angriffsfläche umfasst alles, was der Agent liest. Bei einem echten Agenten ist die Eingabe des Operators nur ein kleiner Teil der Tokens, während 70 Prozent oder mehr des Kontexts oft aus Tool-Ergebnissen und abgerufenem Inhalt bestehen. Diese unausgeglichenen Verhältnisse stellen ebenfalls ein Sicherheitsproblem dar. Der größte Teil dessen, was im Modell vorhanden ist, wenn es eine Entscheidung trifft, stammt von außen, und jedes dieser Tokens könnte eine Anweisung sein. Ihre vertrauenswürdige Eingabe ist im Vergleich zu einer Flut an unvertrauenswürdigen Eingaben nur ein vernachlässigbarer Faktor.
Autonomie beseitigt die menschlichen Verzögerungen. Der Wert eines Agenten ergibt sich daraus, dass er Schleifen ausführen kann, ohne bei jedem Schritt um Erlaubnis zu bitten – doch jeder unüberwachte Schritt bedeutet, dass eine eingeschleuste Anweisung ohne Kontrolle ausgeführt wird. Je autonomer und leistungsstärker der Agent ist, desto größer ist dieses Risiko. Fähigkeiten und die Möglichkeit zur Einschleusung von Anweisungen wachsen zusammen, was bedeutet, dass bei gleichen Bedingungen ein stärkerer Agent für einen Angreifer teurer zu verlieren ist.
Beständigkeit und Ketteneffekte tragen weiter dazu bei. Agenten verfügen über ein Gedächtnis, und dieses kann manipuliert werden: Ein Angreifer pflanzt am Montag eine falsche „Tatsache“ in die Langzeitspeicherung ein, wodurch Entscheidungen wochenlang verfälscht werden. Agenten rufen andere Agenten auf, sodass eine Einflussnahme in den Daten eines Unteragenten sich entlang einer Kette ausbreitet, die niemand von Anfang bis Ende überwacht. Zudem bringen agentbasierte Browser wie Atlas und Comet gleichzeitig einen einsetzbaren Agenten in die Tabellen ein, in denen man sich bei der Bank, im E-Mail-Postfach sowie in der Admin-Konsole des Unternehmens angemeldet hat. Forscher haben bereits Atlas mit als URL getarntem bösartigem Text sowie mit Inhalten, die falsche Erinnerungen einpflanzen, getäuscht. OpenAI’s Reaktion verdient Anerkennung für ihre Ehrlichkeit: Das Unternehmen hat das Produkt durch adversarisches Training sowie automatisierte Red-Teaming-Verfahren gestärkt und den Nutzern klar mitgeteilt, dass das Problem noch nicht vollständig gelöst ist.
Hilfreiche Verteidigungsmaßnahmen
Ehrlich gesagt weiß niemand, wie man ein Modell so gestalten kann, dass es zu 100 % vor Injektionen geschützt ist. Jede der folgenden Schutzmaßnahmen verringert das Risiko, doch keine beseitigt es vollständig. Wahre Sicherheit entsteht durch das Kombinieren mehrerer unvollkommener Schutzschichten und vor allem durch eine Systemgestaltung, bei der eine erfolgreiche Injektion nicht auf etwas Wertvolles zugreifen kann. Hier sind die ehrlichen Schutzmaßnahmen – getrennt von den tröstlichen Illusionen.
Zuerst die „Trifecta“ beseitigen. Das bringt hier mehr Vorteile als alles andere und erfordert kein maschinelles Lernen. Für jeden Agenten prüfen, ob er gleichzeitig alle drei Fähigkeiten besitzt, und falls ja, ob in diesem Kontext eine davon weggelassen werden kann. Ein Agent, der unzuverlässige Webseiten liest, sollte keine Zugangsdaten zu Produktionsdatenbanken haben. Ein Agent, der mit privaten Daten arbeitet, sollte seine Ausgangskommunikation auf eine so strenge Allowlist beschränkt haben, dass kein Platz mehr bleibt, um Geheimnisse zu übermitteln. Die GitHub-Lösung, pro Sitzung nur ein Repository zu verwenden, ist eine Beseitigung der „Trifecta“. Sie funktioniert, weil sie architektonisch begründet ist und nicht probabilistisch.
Verwenden Sie ein Design, das den Planer vor schädlichen Eingaben schützt. Die vielversprechendsten Forschungen betrachten Injektionen als Frage des Datenflusses und nicht danach, ob sie entdeckt werden können. Das Dual LLM-Muster sowie CaMeL, sein strengeres Nachfolgemodell („Defeating Prompt Injections by Design“, 2025), teilen den Agenten in zwei Rollen auf. Ein privilegiertes Modell liest Ihre Anfrage und plant die Schritte, sieht aber niemals unzuverlässiges Material. Ein in Quarantäne befindliches Modell liest das unzuverlässige Material – sei es eine E-Mail oder eine Webseite – verfügt jedoch über keine Werkzeuge und kann nicht handeln. CaMeL geht noch weiter: Der Plan des privilegierten Modells wird in ein eingeschränktes Programm umgewandelt, und ein benutzerdefinierter Interpreter verfolgt den Ursprung jedes Wertes. Alles, was aus einer unzuverlässigen Quelle stammt, wird entsprechend gekennzeichnet, und es kann keine gefährlichen Aktionen auslösen, es sei denn, eine Richtlinie erlaubt es. Das kommt am nächsten an parametrisierten Abfragen für LLMs – einer tatsächlich durchgesetzten Grenze zwischen Befehl und Daten. Es hat jedoch einen Preis: Jemand muss die Richtlinien schreiben, und endlose Genehmigungsanfragen können Nutzer dazu bringen, reflexartig auf „Ja“ zu klicken. Dennoch beruht es auf Prinzipien, und Prinzipien halten stand, selbst gegenüber entschlossenen Angreifern.
Beschränken Sie Aktionen mithilfe einer Berechtigungsleiter. Rangieren Sie jede Aktion danach, wie viel Schaden sie anrichten könnte, und lassen Sie das Sicherheitssystem – nicht die Anweisung – diese Rangfolge durchsetzen. Das Lesen erfolgt geräuschlos, alles, was rückgängig gemacht werden kann, wird protokolliert; schwierig rückgängig zu machende Aktionen (versenden, löschen, bezahlen, zusammenführen) benötigen eine menschliche Bestätigung, die genau zeigt, was gleich geschehen wird, während irreversible und kostspielige Aktionen blockiert oder über einen Genehmigungsprozess geleitet werden, den das Modell nicht beeinflussen kann. Eine Anweisung ist ein Vorschlag, gegen den ein Angreifer argumentieren kann, während eine Regel des Sicherheitssystems eine Barriere darstellt, die er nicht überwinden kann. Dem Modell zu sagen, es solle vor dem Versenden von Geld immer erst fragen, lohnt sich – doch allein reicht das nicht aus. Sicherheit entsteht, wenn der Zahlungscodex einen Token erfordert, den das Modell niemals besitzt.
Wenden Sie das Prinzip des geringsten Privilegs mit begrenzten Zugangsdaten an. Ein Angriff durch Einfügen kann nur in dem Umfang Schaden anrichten, wie es dem Agenten gestattet ist – geben Sie daher jedem Agenten den engsten Zugriffsbereich, einen kurz gültigen Token sowie nur die notwendigsten Werkzeuge, um die Aufgabe zu erledigen. Der GitHub-Vorfall entstand durch einen weitreichenden Token, der sich wie solche verhielt; ein per Repository definiertes OAuth-Bereichsmanagement hätte dies verhindert. Das ist zwar altmodische, langweilige Sicherheitspraxis, doch sie ist besser als jede clevere Prompt-Strategie.
Fügen Sie eine Erkennungsfunktion hinzu, verlassen Sie sich aber nicht darauf. Teams wenden diese Schicht zuerst an, obwohl sie eigentlich zuletzt kommen sollte. Injektionsklassifikatoren sind Modelle, die darauf trainiert sind, „vorherige Anweisungen ignorieren“ sowie seine unzähligen Umformulierungen zu erkennen, und sie fangen tatsächlich viele Angriffe auf. Anthropics Klassifikatoren für den Computergebrauch, Microsofts XPIA-Filter sowie viele Start-ups arbeiten in diesem Bereich. Nutzen Sie sie, da sie die Kosten für Angriffe erhöhen. Seien Sie jedoch klar darüber, was sie leisten können. Ein Klassifikator, der 99 Prozent der Versuche blockiert, klingt hervorragend, zählt aber aus Sicherheitsgründen als Fehlschlag, denn Injektionen sind kein zufälliger Rausch. Der Angreifer hat unendlich viele Versuche und passt sich Ihrem Filter an. Der erste Schritt bei EchoLeak bestand aus einer E-Mail, die darauf ausgelegt war, Microsofts Injektionsklassifikator zu umgehen – und das gelang. Gegen einen angepassten Angreifer stellt eine Leckrate von 1 Prozent bereits ein Hindernis dar. Behalten Sie die Erkennungsfunktion als eine Schicht bei – niemals als Grundlage Ihrer Sicherheit.
Protokollieren Sie alles. Jeder Aufruf eines Tools, jedes heruntergeladene Dokument sowie jede ausgeführte Aktion sollten erfasst und nachvollziehbar sein. Aus Sicht der Sicherheit stellt dies Ihre Erkennungs- und Forensikschicht dar. Im Nachhinein möchten Sie wissen, was der Agent unmittelbar vor dem ungewöhnlichen Verhalten gelesen hat und woher die Anweisungen stammten, sowie Anomaliealarme, wenn er plötzlich Ressourcen außerhalb seines üblichen Musters nutzt. Sie können keinen Angriff verteidigen – oder ihn überhaupt verstehen –, den Sie nicht sehen können. Ein nicht beobachtbarer Agent ist nicht nur schwer zu debuggen; es handelt sich dabei um einen Sicherheitsverstoß, von dem Sie erst von jemand anderem erfahren werden.
Drei Vorfälle zur Untersuchung
Muster bleiben bestehen, wenn sie mit tatsächlichen Ereignissen verbunden sind. Diese drei Vorfälle aus etwa achtzehn Monaten zeigen unterschiedliche Ebenen des Problems.
EchoLeak (Microsoft 365 Copilot, CVE-2025-32711). Besonders auffällig ist das Fehlen jeglicher Klickaktion – mehr noch als irgendein Trick. Entdeckt im Januar 2025, behoben im Mai und im Juni öffentlich gemacht, war es die erste Prompt-Injektion, die ohne jegliche Handlung seitens des Benutzers echte Daten aus einem produktiven KI-System abrief. Dabei wurden vier Ausweichmethoden genutzt: eine E-Mail, die dazu diente, den XPIA-Klassifikator zu umgehen, Markdown-Links im Referenzstil, die eine Löschung der Links verhinderten, ein Bildtag, der eigenständig geladen wurde und eine Ausgangsanfrage sendete, sowie eine in die Weiße Liste aufgenommene Teams-Preview-API, die als Relais diente, damit die Daten über einen genehmigten Weg abgeleitet werden konnten. Jede Kontrollmaßnahme, die Microsoft hatte, war für sich genommen sinnvoll. Der Angreifer fand jedoch die Lücken dazwischen. Eine Reihe von Erkennungsschichten bedeutet auch eine Reihe von Lücken, und ein geduldiger Angreifer prüft alle davon.
Der GitHub MCP-Raub (Invariant Labs, Mai 2025). Dies wurde bereits behandelt, doch die wichtigste Erkenntnis lohnt es, sie nochmals zu betonen: Nichts funktionierte fehlerhaft. Keine Anmeldeinformationen versagten, und das Modell blieb intakt. Ein allgemeiner Zugriffstoken, ein Agent, der von einem Angreifer verfasste Probleme liest, sowie die Möglichkeit, eine öffentliche PR zu öffnen, bildeten zusammen die Schwachstelle. Es gab keinen Ausnutzungscode oder einen Speicherfehler, der behoben werden musste – lediglich drei Funktionen, die niemals denselben Sitzungskontext teilen sollten. Genau das macht die Sicherheit von Agenten zu einem neuen Fachgebiet. Der Fehler liegt in der Weise, wie die einzelnen Komponenten miteinander kombiniert werden, nicht in einer bestimmten Komponente selbst.
Die agentbasierten Browser (Atlas und Comet, Ende 2025). Sobald ChatGPT Atlas sowie Perplexitys Comet veröffentlicht wurden, zeigten Forscher umgehend Injektionen in das Omnibox-Feld, bei denen als Webadresse getarnter Text als Anweisung ausgeführt wurde, sowie Speicheralle-Angriffe, die von einer Sitzung zur nächsten falschen Kontexte hinterließen. Die gemeinsame Verortung macht diesen Fall besonders problematisch: Der injizierbare Agent befindet sich dort, wo man gleichzeitig mit seinem Bankkonto, E-Mail-Konto sowie den Admin-Konsolen authentifiziert ist – diese drei Komponenten befinden sich standardmäßig am sichersten Ort. OpenAI reagierte mit einem ehrlichen Ansatz für die Branche, indem es adversarisches Training, automatisierte Red-Teaming-Tests einsetzte und offen zugab, dass das Problem noch nicht gelöst ist. Man sollte ihren Worten Glauben schenken und so entwickeln, als würde der Browser-Agent letztendlich getäuscht werden.
Was man schichtweise bewerten sollte
Denken Sie schichtweise und wählen Sie für jede Schicht etwas aus.
- Verteidigungsmechanismen auf Basis von Designmustern: CaMeL sowie das Dual LLM-Muster. Sie trennen die Planung von unzuverlässigen Daten ab und verfolgen die Herkunft dieser Daten, wodurch die stärksten Garantien gewährleistet werden.
- Klassifizierer gegen Injection-Angriffe: Anthropics Klassifizierer, Microsoft XPIA, Lakera Guard, PromptArmor sowie protectai/rebuff. Sie melden feindlichen Inhalt in unzuverlässigen Eingaben an, erhöhen dadurch die Kosten, ohne eine vollständige Abschottung zu schaffen.
- Gateways und Durchsetzung von Richtlinien: Docker MCP Gateway-Interceptoren, Invariant Guardrails sowie Ausgangs-Allowlists. Diese unterbrechen das Angriffsmodell durch Richtlinien, indem sie Sitzungen begrenzen, den Zugriff auf verschiedene Ressourcen blockieren und den Ausgangsverkehr einschränken.
- Red-Team-Tools und Benchmarks: AgentDojo, AgentDyn, BIPIA, CyberSecEval sowie deepteam, die es ermöglichen, Injection-Tests wiederholbar und messbar durchzuführen.
Eine Regel, die Ärger vermeidet: Kaufen Sie kein einziges Produkt und betrachten Sie sich dadurch nicht als geschützt. Jeder der oben genannten Punkte stellt eine Schicht dar, und der Schlüssel ist, dass keine einzelne Schicht ausreicht. Eine solide Vorgehensweise kombiniert Verteidigungsmechanismen nach Designmustern, eingeschränkte Zugriffsrechte, eine Berechtigungsstruktur, einen Klassifizierer sowie vollständige Rückverfolgbarkeit – ausgewählt so, dass selbst das Überwinden einer Schicht dem Angreifer weiterhin Hindernisse in den Weg legt.
Fehlermöglichkeiten in der Praxis
- Die Exfiltrationskette. Unzuverlässiger Inhalt weist den Agenten an, private Daten zu sammeln und sie auszusenden, wie bei EchoLeak und GitHub MCP. Gegen dieses Vorgehen hilft es, die drei Komponenten dieser Kette zu unterbrechen, Egress-Allowlists zu verwenden, den Datenfluss zu überwachen (CaMeL) sowie die Zugriffsberechtigungen einzuschränken.
- Der verwirrte Stellvertreter. Eingefügter Inhalt veranlasst den Agenten dazu, eine vom Benutzer nie gewünschte Aktion auszuführen, wie das Versenden einer E-Mail, das Löschen einer Datei oder die Freigabe einer Transaktion. Dagegen hilft eine Genehmigungsstruktur, bei der eine Person jede bedeutende Aktion freigeben muss, wobei die entsprechende Regel im Kontrollsystem gespeichert ist.
- Zero-Click-Angriffe. Es ist keine Benutzerinteraktion erforderlich, da bereits die normale Hintergrundabfrage des Agents als Auslöser dient, wie bei den automatisch geladenen Bildern in EchoLeak. Man sollte automatische Abrufe und externe Darstellungen streng kontrollieren, den Datenabfluss überwachen und alles, was passiv konsumiert wird, als feindlich betrachten.
Ein wöchentlicher Sicherheits-Check
Es handelt sich dabei um eine kleine, konkrete Maßnahme, die anhand eines bereits vorhandenen Agents umgesetzt werden kann.
Tag 1: Kartieren Sie die „Trifecta“-Funktionen. Nehmen Sie jeden laufenden Agenten und notieren Sie, auf welche privaten Daten er Zugriff hat, welche unzuverlässigen Inhalte er verarbeitet und wie er Daten nach außen senden kann. Jeder Agent, der alle drei Funktionen besitzt, rückt an die Spitze der Liste. Diese Übersicht ist das wertvollste Sicherheitsdokument, das Sie je erstellen werden – und dafür reicht bereits ein Nachmittag aus.
Tag 2: Brechen Sie mindestens eine Seite jeder Trifecta auf. Entziehen Sie jedem risikoreichen Agenten in dieser Einstellung eine Fähigkeit. Teilen Sie ihn in zwei Agenten mit eng definierten Aufgaben auf, verringern Sie ihre Berechtigungen oder beschränken Sie den Ausgangsverkehr auf eine Allowlist. Nicht alle drei können immer entfernt werden, aber das Entfernen nur eines ist besser als wochenlanges intensives Absichern.
Tag 3: Erstellen Sie die Berechtigungsstruktur. Listeten Sie alle Aktionen auf, die der Agent ausführen kann, und ordnen Sie sie nach Stufe ein – still, protokolliert, bestätigt und durch den Blast Radius blockiert. Setzen Sie die beiden obersten Ebenen im Code durch, außerhalb der Reichweite des Modells, und überprüfen Sie, ob die Bestätigungsanfragen anzeigen, was tatsächlich geschehen wird.
Tag 4: Greifen Sie Ihren eigenen Agenten an. Bereiten Sie zehn feindliche Eingaben vor, darunter eine mit Sprengfallen versehene Seite, eine Nachricht, ein Problem, eine Einladung, ein PDF mit unsichtbarem Text sowie ein Bild, dessen Alt-Text Befehle enthält. Führen Sie den Agenten gegen jede dieser Eingaben in einer Sandbox aus und beobachten Sie, was passiert. Etwas wird funktionieren – und wenn Sie es selbst finden, ist das besser, als wenn es jemand anderes tut. Ein Benchmark wie AgentDojo macht die Übung wiederholbar.
Tag 5: Fügen Sie eine Erkennungsfunktion hinzu und halten Sie Ihre Erwartungen zurück. Setzen Sie einen Injektionsklassifikator vor unzuverlässige Eingaben und dokumentieren Sie, was er als verdächtig markiert. Es handelt sich dabei um einen Rauchalarm, der die Kosten für Angreifer erhöht, aber nicht um eine echte Barriere. Senden Sie die Ausgabe des Klassifikators in die Protokollierung, die Sie am Tag 6 aktivieren werden.
Tag 6: Aktivieren Sie zur Sicherheit das Tracking. Stellen Sie sicher, dass jeder Aufruf einer Tool, jede Abfrage sowie jede Aktion mit einem klaren Verantwortlichen aufgezeichnet werden, und legen Sie einen Alarm für Ressourcenzugriffe fest, die sich von den normalen Mustern unterscheiden. Falls bereits Tracking vorhanden ist, ändern Sie lediglich die Konfiguration – Sie starten kein neues Projekt.
Tag 7: Schreiben Sie alles auf und testen Sie nach jeder Änderung erneut. Injektionsresistenz ist kein Meilenstein, den man erreicht, sondern eine Eigenschaft, die man ständig aufrechterhält. Jedes neue Tool, jede Datenquelle oder jede neue Funktion kann eine zuvor beseitigte Schwachstelle wieder aktivieren; fügen Sie daher zur Überprüfungsliste die Frage „Öffnet dies die Schwachstelle erneut?“ hinzu und führen Sie die Angriffe vom Tag vier erneut durch, wenn die Antwort möglicherweise „ja“ lautet.
Kein sauberer Abschluss
Die Problematik der Prompt-Injektion ist noch nicht gelöst, und es ist möglicherweise nicht möglich, sie auf die gleiche Weise zu lösen wie die SQL-Injektion, denn die Eigenschaft, die diese Modelle nützlich macht – nämlich Anweisungen in Alltagssprache befolgen zu können – ist zugleich die, die sie anfällig für Ausnutzung macht, und niemand weiß, wie man das Eine ohne das Andere erreichen kann. Die Entwickler von Frontier-Browsern sprechen nun offen darüber, was die ermutigendste Entwicklung in diesem Bereich ist: Die Branche gibt es auf, so zu tun, als würde ein intelligenteres Modell das Problem beseitigen.
Das Warten auf eine Lösung ist kein Plan. Der Plan besteht darin, dass die Agenten auch nachdem das Modell getäuscht wurde, sicher bleiben – denn das wird irgendwann passieren. Das lenkt die ingenieurtechnischen Bemühungen von klügeren Systemanweisungen, die Vorsicht fordern, hin zur Struktur, die das Modell umgibt. Durchbrechen Sie dieses Dreifachproblem, planen Sie weiterhin unabhängig von unzuverlässigen Daten, beschränken Sie jede Berechtigung, stellen Sie jede entscheidende Aktion hinter eine Barriere, die das Modell nicht überwinden kann, und beobachten Sie alles. All das befindet sich im Kontrollsystem und nicht im Modell.
Das Modell ist ein leistungsstarker, vertrauensvoller und manipulierbarer Bestandteil, und das Kontrollsystem ist die Möglichkeit, es dennoch sicher einzusetzen. Machen Sie das Modell zu Ihrer Sicherheitsgrenze, und Sie werden überrannt. Legen Sie die Grenze außerhalb davon, unter Ihrer Kontrolle, und Sie haben eine Chance.
Verwandte Artikel
- DS-STAR erläutert: Googles Data-Science-Agent und warum seine Nutzung erfolgreich ist — Eine detaillierte Einführung in Googles DS-STAR-Data-Science-Agent: seine sieben Module, der DS-STAR+-Berichtszyklus, die veröffentlichten Anweisungen, die Ablationsergebnisse sowie die offenen Einschränkungen.
- Praktische Hinweise: Ich betreibe einen AI-Code-Agent lokal – und seine Leistung ist fast doppelt so hoch — Eine ausführliche Anleitung zu „Praktische Hinweise: Ich betreibe einen AI-Code-Agent lokal – und seine Leistung ist fast doppelt so hoch“: Verträge, Überprüfungen sowie Code-Blöcke, die Teams nutzen können, die dieses Konzept implementieren.