Prompt Injection und KI-Agenten: Das Problem ist strukturell, was CaMeL vorschlägt

In den Hochglanzpräsentationen von KI-Produkten wird oft ein feiner Unterschied übersehen: der zwischen einem Modell, das antwortet, und einem Agenten, der handelt. Ersteres verarbeitet Text und gibt Text zurück. Letzterer liest E-Mails, öffnet Dokumente, surft im Web, ruft Zahlungs-APIs auf und schreibt Code im Repository des Unternehmens. Dieser Sprung vom „Satzgenerator“ zum „Aufgabenlöser“ ist der Grund dafür, dass die Sicherheit von KI-Agenten im Jahr 2026 zu einem Thema für die Vorstandsetagen geworden ist.

Gartner hat es am 9. Juni schwarz auf weiß dargelegt und Prompt Injection zum zweiten Mal in Folge auf Platz eins der KI-Bedrohungen gesetzt. Der Grund dafür ist fast trivial zu formulieren, aber komplex zu lösen: Agenten vervielfachen die Punkte, an denen sich ein Text in einen Befehl verwandeln kann. Eine E-Mail, ein angehängtes PDF, eine Bewertung auf einer Reise-Website oder sogar eine README-Datei auf GitHub werden zu potenziellen Trägern von Anweisungen, die der Benutzer nie geschrieben oder genehmigt hat.

Die Kernidee vor den technischen Details lautet: Je operativer ein KI-System wird, desto mehr bedarf es derselben Vorsichtsmaßnahmen, die kritische Software seit Jahrzehnten anwendet – Privilegentrennung, Verifizierung von Inputs, Rückverfolgbarkeit von Aktionen. Es ist dieselbe Lektion, die die Informatik bei Datenbanken (SQL Injection) und im Web (Cross-Site Scripting) gelernt hat, angewandt auf eine neue Domäne, in der der Angreifer keinen Code schreibt, sondern Sätze in natürlicher Sprache.

Das in den Daten verborgene Risiko

Die technische Definition gemäß den Top 10 von OWASP für LLM-basierte Anwendungen unterscheidet zwei Hauptvarianten. Die direkte Injektion ist der explizite Versuch, bei dem der Benutzer schreibt: „Ignoriere die vorherigen Anweisungen und tue X“ – ein leicht vorstellbarer Angriff, der relativ einfach zu filtern ist. Die indirekte Injektion ist tückischer, da der bösartige Text nicht vom Benutzer stammt, sondern aus externen Inhalten, die der Agent im normalen Verlauf seiner Arbeit verarbeitet – ein freigegebenes Dokument, eine Webseite, das Notizfeld eines Tickets.

Der Punkt, so erklären die Forscher des CaMeL-Papers, das wir gleich analysieren werden, ist, dass das Problem nicht nur das Sprachmodell betrifft, sondern das gesamte System um das Modell herum: den Kontext, den es erhält, die Tools, auf die es zugreifen kann, die Berechtigungen, mit denen es arbeitet, und die von ihm erzeugten Outputs. Ein Modell erhält, egal wie gut es ausgerichtet ist, an seinem Eingang eine Sequenz von Token, deren Herkunft nicht unterscheidbar ist, wie ICT Security Magazine bei der Analyse des Falls EchoLeak rekonstruiert hat: Dem Modell ist es egal, ob dieser Text aus dem System-Prompt des Entwicklers oder aus einer vor einer Stunde empfangenen E-Mail stammt – alles landet im selben Kontextfenster mit demselben impliziten Vertrauensniveau.

Ein einfaches Beispiel hilft, die Idee zu verdeutlichen. Ein Agent, der eine E-Mail zusammenfassen soll, könnte auf einen versteckten Text stoßen, der vielleicht mit unsichtbaren Zeichen geschrieben oder so formatiert ist, dass er wie Teil des legitimen Inhalts aussieht, und ihn anweist, vertrauliche Informationen an eine externe Adresse weiterzuleiten. Der Benutzer hat nur nach einer Zusammenfassung gefragt, der Agent führt aber auch den versteckten Befehl aus, weil für ihn kein semantischer Unterschied zwischen „was der Benutzer will“ und „was laut Dokument zu tun ist“ existiert.

Warum Agenten die Regeln ändern

Herkömmliche Chatbots, die sich auf reine Konversation beschränken, begrenzen den potenziellen Schaden auf die Grenzen der Konversation selbst: Im schlimmsten Fall geben sie eine peinliche oder falsche Antwort. Agenten tun das nicht. Sie haben Zugriff auf reale Tools, oft mit weitreichenden Privilegien, und das verändert die Natur des Risikos von „falschem Output“ hin zu einer „schädlichen und unumkehrbaren Aktion“. IBM beschreibt das gut: Die Kombination aus automatisierter Entscheidungsfindung und der Fähigkeit, externe Tools aufzurufen, schafft eine Angriffsfläche an zwei Fronten – Angreifer können das Verhalten des Agenten manipulieren und ihn dazu verleiten, Tools missbräuchlich zu verwenden, oder das Tool direkt mit klassischeren Vektoren wie SQL-Injection angreifen.

Hinzu kommt ein Problem der Beobachtbarkeit. Ein Sprachmodell liefert von Natur aus probabilistische Inferenz, keinen deterministischen und Zeile für Zeile überprüfbaren Algorithmus. Dies macht es zumindest teilweise unvorhersehbar, was der Agent tun wird, wenn er mit einer noch nie gesehenen Eingabe konfrontiert wird, was die Arbeit der Teams, die Vorfälle überwachen und darauf reagieren müssen, enorm erschwert.

Das Risiko wächst im Verhältnis zu drei Faktoren, die zusammenwirken und nicht einzeln auftreten: der Zugriff auf private Daten, die Exposition gegenüber nicht vertrauenswürdigen Inhalten und die Verfügbarkeit eines Kanals nach außen, um Informationen abfließen zu lassen. Wenn ein Agent alle drei Faktoren vereint – er liest sensible Daten, verarbeitet Text, den er nicht kontrolliert, und kann externe Systeme kontaktieren –, wird die Angriffsfläche strukturell verwundbar. Dies gilt unabhängig davon, wie ausgeklügelt der System-Prompt ist, der ihn anweist, sich gut zu verhalten. Aus diesem Grund muss Sicherheit als Systemarchitektur konzipiert und darf nicht einem auf den Prompt angewendeten Filter überlassen werden.

Der am häufigsten zitierte Fall des Jahres 2025 veranschaulicht diese Dynamik perfekt. Microsoft hat im Juni-Patchday stillschweigend eine kritische Schwachstelle in Microsoft 365 Copilot behoben, die als EchoLeak bekannt ist (CVE-2025-32711, CVSS-Score 9.3). Sie ermöglichte den Abfluss von Daten ohne jeglichen Klick des Opfers: Es genügte eine kunstvoll formatierte E-Mail, die Monate später von Copilot während einer völlig gewöhnlichen Arbeitsanfrage verarbeitet wurde, um den Datenabfluss an eine externe Domäne auszulösen, die als vertrauenswürdiger Endpunkt getarnt war. Keine Schadsoftware, kein Klick auf Links, nur falsch interpretierter Text.

Was CaMeL vorschlägt

Im Juni 2025 veröffentlichte eine Gruppe von Forschern von Google DeepMind und der ETH Zürich ein Paper mit dem Titel „Defeating Prompt Injections by Design“. Es schlägt einen anderen Ansatz vor als frühere Versuche, das Modell selbst robuster zu machen. CaMeL, ein Akronym für CApabilities for MachinE Learning, verändert nicht das Modell, sondern baut eine schützende Systemebene darum herum. Dabei orientiert es sich an Konzepten, die sich in der traditionellen IT-Sicherheit bereits bewährt haben, wie der Integrität des Kontrollflusses und der Zugriffskontrolle.

Die Ausgangsintuition greift eine Idee auf, die 2023 von dem Entwickler Simon Willison vorgeschlagen wurde, das „Dual LLM“-Muster: ein privilegiertes Modell (Privileged Model), das nur die ursprüngliche Anfrage des Benutzers sieht und die Aktionen plant, und ein unter Quarantäne stehendes Modell (Quarantined Model) ohne die Fähigkeit, Tools aufzurufen, das die nicht vertrauenswürdigen Inhalte (E-Mails, Dokumente, Webseiten) verarbeitet. Die auf dem Papier elegante Idee stößt jedoch an Grenzen: Selbst wenn man die Planung von den schmutzigen Daten isoliert, kann ein Angreifer immer noch die an die Tools übergebenen Argumente manipulieren und so den Datenfluss umleiten, ohne die Abfolge der geplanten Aktionen anzutasten. Dies ist das agentische Äquivalent zu einer SQL-Injection, die nicht die Struktur der Abfrage verändert, sondern nur deren Parameter korrumpiert.

CaMeL überwindet diese Grenze, indem es aus der Anfrage des Benutzers (die als vertrauenswürdig vorausgesetzt wird) explizit sowohl den Kontrollfluss als auch den Datenfluss in Form von Python-Code extrahiert, der vom privilegierten Modell generiert und von einem benutzerdefinierten Interpreter ausgeführt wird. Auf diese Weise können aus nicht vertrauenswürdigen Quellen abgerufene Daten niemals den logischen Pfad der Ausführung beeinflussen, sondern nur deren Inhalt, und dies auch nur innerhalb der durch explizite Regeln gesetzten Grenzen. Bild aus dem offiziellen CaMeL-Paper

Capability, Policy, kontrollierte Flüsse

Das technische Herzstück des Systems basiert auf einem aus der Betriebssystemsicherheit entlehnten Konzept, der Capability: ein Metadaten-Tag, das jedem Wert zugeordnet ist, der das Programm durchläuft, und das dessen Herkunft und die autorisierten Empfänger registrieren kann. Wenn der Agent eine Datei aus einem Cloud-Speicher abruft, trägt diese Datei die Information darüber, wer sie freigegeben hat und wer sie lesen darf – ähnlich wie ein Paket, das mit einem eigenen Lieferschein ankommt. Wenn der vom Modell generierte Code später versucht, diese Datei an eine nicht autorisierte E-Mail-Adresse zu senden, blockiert der Interpreter die Aktion vor der Ausführung und bittet gegebenenfalls den Benutzer um explizite Bestätigung.

Neben den Capabilities wirken Security Policies – in Python geschriebene Funktionen, die definieren, was mit bestimmten Daten geschehen darf, und die bei jedem Aufruf eines Tools überprüft werden. Im Paper wird ein Beispiel für das Erstellen von Kalenderereignissen gezeigt: Titel, Beschreibung, Ort und Uhrzeit müssen für alle Teilnehmer lesbar sein, es sei denn, letztere stammen direkt aus einer vertrauenswürdigen Anweisung des Benutzers. Die Granularität ist so fein, dass beliebig komplexe Logiken möglich sind, wodurch sowohl eine zu starke Einschränkung (die den Nutzen des Agenten mindert) als auch eine zu große Freizügigkeit (die Angriffen wieder Tür und Tor öffnet) vermieden wird.

Die Zahlen der Evaluierung, die auf dem Benchmark AgentDojo durchgeführt wurde, sind aufschlussreich. Mit Claude 4 Sonnet und vergleichbaren Modellen reduziert CaMeL erfolgreiche Angriffe praktisch auf Null – im Vergleich zu hunderten von Erfolgen, die gegen dieselbe Modell-Suite bei Verwendung nativer Tool-Calling-APIs erzielt wurden. Der Preis dafür ist ein Verlust an Nützlichkeit (der Prozentsatz der erfolgreich abgeschlossenen legitimen Aufgaben), der je nach Domäne variiert und besonders bei unklaren oder weniger dokumentierten Aufgaben spürbar ist, andernorts jedoch im Rahmen bleibt. Der Rechenaufwand liegt bei etwa dem 2,8-fachen an Token (sowohl im Input als auch im Output) im Vergleich zum nativen Tool-Calling – ein realer Aufwand, der nach Ansicht der Autoren angesichts der gewonnenen Garantien vertretbar ist.

Technischer Hinweis: CaMeL befasst sich auch mit Side-Channels, beispielsweise der Möglichkeit, ein privates Datum abzuleiten, indem man indirekt beobachtet, wie oft ein bestimmter, von seinem Wert abhängiger Aufruf ausgeführt wird. Ein Problem, das im Paper als ungelöst anerkannt und mit den Techniken des Return-Oriented Programming verglichen wird, die in traditionellen Systemen die Control Flow Integrity noch immer teilweise umgehen.

Governance: Vertrauen reicht nicht aus

Für diejenigen, die sich mit Compliance, Unternehmenssicherheit oder öffentlicher Verwaltung befassen, übersetzt sich der technische Diskurs in eine einfachere Frage: Wie macht man einen Agenten nicht nur präzise, sondern auch steuerbar, verifizierbar und überprüfbar (auditable). Microsoft nennt in seinem Architektur-Leitfaden für Agenten drei grundlegende Säulen für eine verantwortungsvolle Entwicklung: die Eignung für den Zweck, den zuverlässigen Betrieb über die Zeit und eine dritte Säule, die den Kern des Problems zusammenfasst: Vertrauen, Rückverfolgbarkeit und Transparenz – also die konkrete Möglichkeit für Benutzer und Administratoren, zu wissen, wo die Daten liegen, wie sie verwendet werden, und die Herkunft jeder vom System angezeigten Information zu überprüfen.

Hier kommt ein Detail ins Spiel, das CaMeL über den reinen Sicherheitsbereich hinaus interessant macht: Der Datenflussgraph, den der Interpreter während der Ausführung aufbaut, kann in der Benutzeroberfläche wiederverwendet werden, um die Quelle eines Inhalts anzuzeigen. So kann der Leser beispielsweise erkennen, dass eine angebliche Nachricht „von Google“ in Wirklichkeit aus einer unbestätigten Quelle stammt. Rückverfolgbarkeit also nicht als bürokratische Pflicht, sondern als reales Abwehrwerkzeug gegen Phishing, das vom Agenten selbst transportiert wird.

Der regulatorische Rahmen bewegt sich schnell. Der europäische AI Act verpflichtet in Artikel 15 Hochrisikosysteme – Banken, das Gesundheitswesen, kritische Infrastrukturen –, Robustheit gegenüber Manipulationsversuchen durch unbefugte Dritte nachzuweisen, bei Strafen von bis zu 7 % des weltweiten Umsatzes ab August 2026. In Italien kommen die seit Januar geltende NIS2-Richtlinie und die ACN-Leitlinien vom Februar hinzu, mit einer spezifischen Bewertung der Prompt Injection für die öffentliche Verwaltung: drei sich überschneidende Regelungen, die jeden Vorfall noch vor einem technischen zu einem rechtlichen Problem machen. Bild aus dem offiziellen CaMeL-Paper

Wo es funktioniert und wo nicht

Die Stärken von CaMeL, im Licht der Daten des Papers betrachtet, sind konkret: Es reduziert das blinde Vertrauen in externe Texte drastisch, führt eine verifizierbare architektonische Barriere anstelle einer x-ten Anweisung im Prompt ein und packt das Problem an der Wurzel, anstatt die Symptome zu filtern. Im Vergleich zu anderen in AgentDojo verfügbaren Abwehrmethoden (Tool-Filter, Spotlighting, Prompt-Sandwiching) senkt CaMeL erfolgreiche Angriffe praktisch auf Null, während die Alternativen bei 949 getesteten Versuchen fünf bis vierundzwanzig durchlassen.

Die ebenso konkreten Grenzen verdienen das gleiche Gewicht. Die Implementierungskosten sind hoch: Der Aufbau eines auf Capabilities basierenden Systems erfordert einen Paradigmenwechsel, nicht nur die Installation eines Plugins, und funktioniert nur dann gut, wenn das gesamte Ökosystem der Tools kooperiert – eine Einschränkung, die sich verkompliziert, sobald der Agent mit Drittanbieterdiensten außerhalb der direkten Kontrolle der Entwickler interagieren muss. Zudem besteht das Risiko, das denjenigen, die mit granularen Berechtigungssystemen arbeiten, bestens bekannt ist, der „Bestätigungsmüdigkeit“: Wenn sich die Bestätigungsanfragen häufen, neigt der Benutzer dazu, selbst gefährliche Aktionen mechanisch abzufeiern, wodurch ein Teil des Nutzens verloren geht.

Die Autoren selbst sagen es in einem Punkt unmissverständlich: Prompt Injection ist nicht „gelöst“. CaMeL schützt nach eigenem Bekunden weder vor Angriffen, die nur den dem Benutzer angezeigten Text verändern, ohne den Datenfluss zu berühren – wie eine verzerrte Zusammenfassung einer E-Mail, die keinen Abfluss verursacht –, noch vor induziertem Phishing, wenn dieses auf der Sprachebene bleibt. Offen bleibt zudem die Front der Side-Channels, also von Seitenkanälen, die sich selbst in traditioneller Software nur schwer völlig schließen lassen.

Der Stand der Technik im Jahr 2026

Der Fall CaMeL fügt sich in eine Reihe realer Vorfälle ein, die dessen Dringlichkeit bestätigen. Neben EchoLeak gab es 2025 eine Schwachstelle für Remote Code Execution in GitHub Copilot und Visual Studio Code (CVE-2025-53773), die sich über scheinbar harmlose README-Dateien wie ein Wurm zwischen Repositories verbreiten konnte, sowie einen Angriff auf ServiceNow Now Assist, bei dem ein Benutzer mit geringen Privilegien über ein Ticket-Feld einen Agenten mit höheren Privilegien dazu verleitete, nicht autorisierte Aktionen auszuführen – unter Ausnutzung des impliziten Vertrauens zwischen Agenten derselben Plattform.

Der schwerwiegendste Fall, von Anthropic in einem öffentlichen Bericht rekonstruiert und von der Fachpresse aufgegriffen, beschreibt eine Spionagekampagne, die einer staatlich unterstützten Gruppe zugeschrieben wird. Diese kompromittierte ein Agenten-Setup, indem sie den Angriff in eine Abfolge kleiner und scheinbar legitimer Anfragen zerlegte und das Modell davon überzeugte, einen autorisierten Penetration Test durchzuführen. Eine Anekdote, die stark an die Logik des „Snow Crash“ erinnert, den Neal Stephenson in seinem Roman von 1992 entworfen hat: ein Virus, der sich nicht über einen Fehler im Code verbreitet, sondern über die Bereitschaft des Systems, das, was ihm gezeigt wird, blind auszuführen.

OWASP hat in der Überarbeitung für Agentenanwendungen vom Dezember 2025 spezifische Unterkategorien hinzugefügt, wie die Injektion durch Tool-Missbrauch und die persistente Injektion im Gedächtnis des Agenten: Kategorien, die in der Ära isolierter Chatbots undenkbar waren, heute jedoch zentral sind, da das LLM als Orchestrator vernetzter Systeme fungiert. Cisco schätzt, dass 83 % der Unternehmen die Einführung von Agentensystemen planen, während sich nur 29 % für bereit erklären, diese angemessen zu schützen – eine Lücke, die denjenigen, die mit bestimmten Survival-Horror-Spielen vertraut sind, das Gefühl vermittelt, in einem dunklen Korridor voranzuschreiten, mit mehr Munition als Schlössern.

Die Umgebung bauen, nicht nur das Modell

Das problemfrei zusammengefasste Problem lautet nicht „den Prompt verteidigen“, sondern Systeme zu entwerfen, die in der Lage sind, Anweisungen, Daten und Aktionen klar zu unterscheiden – ähnlich wie ein gutes bürokratisches Prüfspiel lehrt, das echte Dokument vom gefälschten zu unterscheiden, ohne jemals dem äußeren Anschein zu trauen. CaMeL ist mit all seinen erklärten Grenzen gerade deshalb als Fallstudie nützlich, weil es eine reifere Richtung für die Branche aufzeigt: Sicherheit, die in das Systemdesign integriert ist, anstatt darauf zu hoffen, dass sich das Modell gut verhält.

Für das Publikum, das diese Systeme nicht direkt implementiert, sondern sie einführt, finanziert oder reguliert, lautet die praktische Übersetzung: Es reicht nicht aus, dem Modell beizubringen, sich gut zu verhalten. Man muss die Umgebung bauen, in der es agiert – mit minimalen Privilegien, vollständiger Rückverfolgbarkeit und menschlicher Bestätigung für unumkehrbare Aktionen. Eine Lektion, die so alt ist wie die Informatik selbst, wiederentdeckt jedes Mal, wenn eine neue Technologie verspricht, alles zu vereinfachen, und am Ende dieselben Probleme mit einem anderen Vokabular aufwirft.