Die wichtigste Lektion aus den aktuellen Fällen rund um agentische KI ist nicht: „KI wird böse.“ Das ist die falsche Geschichte, bequem dramatisch und technisch zu weich.
Wir haben hier schon öfter über KI im Angriff geschrieben: über Claude Mythos als Brandbeschleuniger, nicht Magie, über alte Security und schnellere Angreifer, über Phishing, Social Engineering und automatisierten Security-Slop. Die These war dabei nie, dass KI plötzlich Zauberei betreibt. Die These war: Angreifer werden KI dort einsetzen, wo sie Reibung senkt und operative Arbeit billiger macht.
JadePuffer sieht aus wie der erste sauber dokumentierte Fall, in dem diese These eine neue Stufe erreicht: nicht nur KI-unterstützte Angreifer, sondern ein real beobachteter agentischer Angreifer.
Damit liegen zwei verschiedene Risiken auf dem Tisch. Wenn Angreifer selbst Agenten einsetzen, wird aus alter Angriffstechnik eine billigere, schnellere, adaptivere Operationskette. Wenn Verteidiger und Unternehmen eigenen Agenten echte Reichweite geben, wird Prompt Injection nicht mehr nur ein Textproblem. Sie wird ein Autorisierungsproblem.
Ein Chatbot, der Unsinn schreibt, ist ein Qualitätsproblem. Ein Agent, der mit Browser, Wallet, API-Keys, Cloud-Zugriffen oder internen Datenbanken arbeitet, ist etwas anderes. Dann ist Text nicht mehr nur Eingabe. Er wird Teil einer Ausführungskette — entweder als Arbeitsmaterial eines legitimen Agenten oder als Operationslogik eines Angreifers.
Und genau dort brechen viele Sicherheitsmodelle gerade auf.
Der erste beobachtete agentische Angreifer
Die aktuellen Berichte zeigen zwei Seiten derselben Entwicklung. JadePuffer ist dabei nicht einfach „noch ein Prompt-Injection-Fall“. JadePuffer ist die härtere Nachricht.
BleepingComputer und SecurityWeek berichten über Sysdigs Analyse eines Angriffs, bei dem ein LLM-Agent nach der Ausnutzung einer Langflow-Schwachstelle eine mehrstufige Ransomware-Operation automatisiert haben soll. Sysdig beschreibt JadePuffer als ersten dokumentierten agentic threat actor: nicht als Angreifer, der irgendwo KI-Hilfe beim Schreiben von Phishing-Texten nutzt, sondern als Angriffsfähigkeit, die operativ durch einen Agenten geliefert wird.
Das ist eine andere Klasse. Bei Phishing und Social Engineering war KI zuerst vor allem Skalierungs- und Qualitätswerkzeug: bessere Texte, mehr Varianten, schnellere Anpassung, mehr Sprachen, weniger menschliche Arbeit. Bei JadePuffer verschiebt sich der Punkt von „KI unterstützt den Angreifer“ zu „der Agent führt Teile der Intrusion selbst aus“.
Der Einstieg lief über CVE-2025-3248, eine kritische Langflow-Lücke zur unauthentifizierten Codeausführung. Das ist als Symbol fast zu passend: Angegriffen wurde nicht irgendein beliebiger Webserver, sondern eine internet-exponierte Komponente aus dem LLM-/Agenten-Ökosystem selbst. Langflow ist Infrastruktur zum Bau von LLM-Anwendungen und Agent-Workflows. Die Agentenwelle bringt also nicht nur neue Nutzer von Infrastruktur. Sie bringt neue Infrastruktur mit: exponierte Builder, gespeicherte Secrets, Workflow-Engines, API-Keys und Default-Fehler. Das Ökosystem wird selbst zur Angriffsfläche.
Nach dem Einstieg folgten Reconnaissance, Secret-Suche, Credential Harvesting, laterale Bewegung, Persistenz und schließlich Verschlüsselung beziehungsweise Zerstörung von Konfigurationsdaten. Sysdig beschreibt dabei nicht einfach ein Skript, das stur Befehle abarbeitet. Auffällig war gerade das adaptive Verhalten: fehlgeschlagene Logins wurden analysiert, Payloads angepasst, Parser geändert, neue Wege probiert. In einem Beispiel soll der Agent innerhalb von 31 Sekunden von einem fehlgeschlagenen Login zu einer funktionierenden Korrektur gekommen sein.
Später wurden 1.342 Nacos-Konfigurationseinträge in einer Produktionsumgebung verschlüsselt, Tabellen gelöscht und eine Erpressungsnotiz mit Zahlungsadresse hinterlegt. Besonders bitter: Der verwendete Schlüssel wurde offenbar nicht persistent gespeichert oder übertragen. Zahlung hätte also nicht zwingend Wiederherstellung bedeutet. Ransomware, aber mit der Verlässlichkeit eines schlecht beaufsichtigten Automatisierungsjobs und der Geschwindigkeit einer Maschine. Hervorragende Kombination, wenn man Katastrophen mag.
JadePuffer bestätigt damit eine These, die bisher oft noch etwas abstrakt klang: Angreifer werden KI nicht nur für hübschere Ködertexte nutzen. Sie werden sie dort einsetzen, wo sie Arbeit reduziert: beim Erkunden, Kombinieren, Wiederholen, Diagnostizieren und Anpassen von Angriffsschritten. Der Agent muss nicht genial sein. Es reicht, wenn er alte Schwachstellen billig, schnell und ausdauernd gegen schlecht gehärtete Infrastruktur zusammensteckt.
Die zweite Klasse: manipulierte legitime Agenten
Auf der anderen Seite steht Zscalers Analyse indirekter Prompt-Injection-Kampagnen. Dort wurden manipulierte Webseiten und Suchergebnisse genutzt, um autonome Agenten zu beeinflussen. Eine Kampagne tarnte sich als API-Dokumentation für eine Python-Bibliothek und versteckte Anweisungen, die Agenten zu einer Kryptozahlung für einen angeblichen API-Key bewegen sollten. Die Instruktionen lagen nicht nur sichtbar auf der Seite, sondern auch in strukturierten Daten, versteckten HTML-Elementen und CSS-getarnten Blöcken. Eine zweite Kampagne impersonierte DeBank über Typosquatting und versuchte, Agenten die gefälschte Domain als vertrauenswürdige Quelle unterzuschieben.
Zscaler testete das in einer Sandbox mit einem autonomen Agenten, der browsen und Zahlungen ausführen konnte. Vier von 26 getesteten Modellen ließen sich in der Payment-Kampagne zu Zahlungen bewegen. Zwei Modelle klassifizierten in bestimmten Kontexten die betrügerische DeBank-Seite falsch als vertrauenswürdig.
Das ist kein Beweis, dass jeder Agent morgen Geld überweist. Es ist aber ein klarer Beweis, dass die Grenze zwischen „Information lesen“ und „Aktion ausführen“ bei Agenten nicht akademisch ist. Sie ist die Sicherheitsgrenze.
Prompt Injection ist bei Agenten keine Texteingabe mehr
Klassische Prompt Injection wurde lange wie ein kurioser Modellfehler behandelt: Eine Webseite sagt „Ignoriere alle vorherigen Anweisungen“, das Modell wird verwirrt, die Demo sieht lustig aus, alle nicken, dann geht man wieder zur Tagesordnung über.
Das war schon damals zu kurz gedacht. Bei agentischen Systemen ist es endgültig falsch.
Ein Agent konsumiert nicht einfach Text. Er plant, ruft Tools auf, navigiert Webseiten, liest Dokumente, schreibt Tickets, erzeugt Pull Requests, verwendet API-Schlüssel, startet Cloud-Aktionen, kann Zahlungsflüsse anstoßen oder zumindest vorbereiten. Damit wird jeder untrusted Input, den der Agent in seinen Arbeitskontext bekommt, potenziell Teil einer Entscheidungs- und Autorisierungskette.
Das Sicherheitsproblem lautet dann nicht mehr: „Kann der Prompt sauber genug formuliert werden?“
Es lautet:
- Darf dieser Agent diese Aktion überhaupt ausführen?
- Darf er sie aufgrund dieser Informationsquelle ausführen?
- Unter welcher Identität handelt er?
- Welche Rechte sind an diese Identität gebunden?
- Welche Aktionen brauchen menschliche Freigabe?
- Welche Limits greifen, wenn der Agent Unsinn macht?
- Kann man später sauber nachvollziehen, wer oder was welche Entscheidung ausgelöst hat?
Wenn diese Fragen nicht hart beantwortet sind, ist der Prompt nur Dekoration.
Der legitime Agent wurde nicht übernommen. Er hat seine Aufgabe falsch verstanden.
Das macht die zweite Klasse so tückisch. Bei indirekter Prompt Injection sieht der Angriff nicht aus wie ein klassischer Hack des Agenten. Kein Speicherfehler. Kein Shellcode. Kein Rootkit im Modell.
Der Agent arbeitet innerhalb seiner vorgesehenen Funktion. Er liest Webseiten. Er extrahiert relevante Informationen. Er befolgt Anweisungen. Er nutzt Tools. Er automatisiert einen Workflow.
Nur stammt ein Teil der Anweisung aus einer Quelle, die nie Autorität haben durfte.
Das ist der Kern. Nicht „der Agent ist gehackt“, sondern: Der Agent hat einen fremden Befehl in einen erlaubten Arbeitsablauf übernommen. Für Menschen ist diese Unterscheidung intuitiv. Wenn eine Webseite behauptet, sie sei die Bank, prüft ein erfahrener Mensch hoffentlich Domain, Kontext, Erwartung und Risiko. Ein Agent braucht dafür explizite Architektur. Nicht guten Willen. Architektur.
Deshalb sind reine Modell-Guardrails unzureichend. Guardrails können Fehlverhalten reduzieren, aber sie sind keine Berechtigungsgrenze. Ein Sprachmodell kann nicht gleichzeitig der unsichere Parser, der Planer, der Policy-Enforcer, der Auditor und der ausführende Principal sein. Wer das trotzdem baut, baut ein magisches IAM-System aus Text. Das ist keine Sicherheitsarchitektur. Das ist ein Wunschzettel.
Die falsche Verteidigung: bessere Prompts
Natürlich helfen bessere Systemprompts ein Stück weit. Natürlich kann man Agenten sagen, dass sie versteckte Anweisungen ignorieren, Zahlungen nicht ohne Prüfung ausführen und Webseiten nicht blind vertrauen sollen. Das ist nicht nutzlos.
Es ist nur nicht ausreichend.
Denn der Angreifer greift genau die Verarbeitungsschicht an, die diese Regeln interpretieren soll. Wenn die Policy selbst als Text im gleichen Kontext liegt wie fremder Text, ist sie nicht hart getrennt. Dann konkurriert sie mit allem, was der Agent sonst liest, zusammenfasst, priorisiert und in einen Plan überführt.
Einige Modelle werden besser widerstehen als andere. Einige Agent-Frameworks werden robustere Retrieval- und Tool-Patterns haben. Aber das Grundproblem bleibt: Wenn die endgültige Entscheidung über eine gefährliche Aktion im selben probabilistischen Textsystem liegt, das gerade angegriffen wird, fehlt eine Sicherheitsgrenze.
Das gilt besonders für Agenten mit Geld-, Identitäts- oder Infrastrukturwirkung. Kryptozahlungen sind nur das auffällige Beispiel, weil sie so sauber demonstrierbar sind. Dasselbe Muster betrifft Cloud-Ressourcen, SaaS-Adminaktionen, Deployment-Pipelines, Helpdesk-Workflows, CRM-Daten, E-Mail-Aktionen, interne Wissenssysteme und alles, was über APIs steuerbar ist.
Kurz: überall dort, wo ein Agent nicht nur schreibt, sondern wirkt.
Was harte Grenzen bedeuten
Agentensicherheit muss wie Zugriffskontrolle behandelt werden, nicht wie Prompt-Kosmetik.
Erstens: Capability Scoping. Ein Agent braucht nicht „Browserzugriff“. Er braucht definierte, begrenzte Fähigkeiten. Lesen ist nicht Kaufen. Suchen ist nicht Deployen. Zusammenfassen ist nicht Löschen. Eine Tool-Berechtigung sollte nicht grob am Agenten hängen, sondern am konkreten Auftrag, Kontext und Risiko.
Zweitens: Approval Gates. Bestimmte Aktionen gehören nicht in vollautomatische Flows. Zahlungen, Credential-Änderungen, produktive Deployments, Löschoperationen, Rechtevergaben, externe Kommunikation und Datenexporte brauchen explizite Freigabe. Nicht als freundlicher UI-Dialog, den der Agent selbst wegargumentieren kann, sondern als separate Kontrollinstanz außerhalb des Modellkontexts.
Drittens: Identitätsbindung. Agenten dürfen nicht als diffuse Erweiterung eines menschlichen Nutzers laufen. Jeder Agent braucht eine eigene Identität, eigene Rollen, eigene Logs und eigene Limits. Wenn ein Agent über Andreas’ Browser-Session, Admin-Cookies oder persönliche Tokens handelt, ist später nicht mehr sauber trennbar, was menschliche Entscheidung und was Agentenausführung war. Das ist für Incident Response, Haftung und Berechtigungsmodell gleichermaßen schlecht.
Viertens: Transaktionslimits. Wenn ein Agent Zahlungen, Bestellungen, Cloud-Kosten oder externe Aktionen auslösen kann, braucht er harte Budgets, Ratenlimits und Empfängerprüfungen. Ein Agent sollte nicht aufgrund einer Webseite erstmals an eine neue Wallet, einen neuen Lieferanten oder eine neue externe API schreiben dürfen. Neue Gegenparteien sind ein Risikoereignis, kein normaler Parameter.
Fünftens: Quellenbindung. Nicht jede Information darf jede Aktion autorisieren. Eine README aus einem fremden Repository darf einem Coding-Agenten Hinweise geben, aber nicht automatisch Befehle mit Ausführungsrecht. Eine Webseite darf beschrieben werden, aber nicht zur Policy-Quelle werden. Ein Support-Ticket darf einen Arbeitsauftrag enthalten, aber nicht selbst Berechtigungen erhöhen.
Das sind keine exotischen Anforderungen. Das ist normales Security Engineering, nur angewendet auf Agenten.
Agenten machen alte Fehler billiger
Der JadePuffer-Fall zeigt außerdem etwas, das in der KI-Debatte oft verloren geht: Agentische Angriffe brauchen nicht zwingend neue Schwachstellen. Sie machen alte Schwachstellen billiger, schneller und breiter nutzbar.
Langflow war über eine bekannte Schwachstelle erreichbar. Nacos hatte alte Authentifizierungs- und Default-Key-Probleme. Es ging um exponierte Dienste, Secrets in Umgebungen, root-nahe Datenbankzugriffe und mangelhafte Segmentierung. Also um Dinge, die Verteidiger seit Jahren kennen und trotzdem überall wiederfinden.
Der Unterschied ist die Skalierung der Ausführung. Ein Agent kann lange Ketten aus bekannten Techniken zusammenbauen, Fehler diagnostizieren und stumpf weiterprobieren. Nicht brillant. Nicht allwissend. Aber ausdauernd, schnell und billig.
Das senkt die Schwelle. Angriffe, die früher mehr Bedienkompetenz oder manuelle Anpassung brauchten, werden stärker automatisierbar. Und wenn die Zielumgebung ohnehin schwach segmentiert ist, reichen mittelmäßige Entscheidungen oft aus. Angreifer brauchen nicht perfekt zu sein, wenn die Infrastruktur ihnen genug Seil gibt.
Die Verteidigung muss nüchterner werden
Die kommende Agentenwelle wird nicht dadurch sicher, dass man ihr freundlich erklärt, sie solle keine bösen Webseiten glauben. Das ist ein Baustein, kein Sicherheitsmodell.
Die relevante Frage lautet: Was passiert, wenn der Agent falsch liegt?
Wenn die Antwort lautet „dann schreibt er eine schlechte Zusammenfassung“, ist das ein begrenztes Problem. Wenn die Antwort lautet „dann überweist er Geld, löscht Daten, deployed Code, rotiert Secrets, öffnet Firewall-Regeln oder verschickt interne Informationen“, dann ist der Agent ein produktiver Principal und muss auch so behandelt werden.
Das bedeutet: minimale Rechte, getrennte Identität, harte Freigaben, nachvollziehbare Logs, Limits, Quarantäne für untrusted Content, klare Tool-Grenzen und Policy Enforcement außerhalb des Modells.
Agentic AI ist nicht automatisch gefährlich, weil sie „intelligent“ ist. Sie wird gefährlich, wenn man ihr echte Wirkung gibt und dann so tut, als seien Textregeln eine Sicherheitsgrenze.
Der Agent muss nicht gehackt werden.
Es reicht, wenn man ihn beauftragt — und niemand vorher sauber festgelegt hat, wessen Auftrag überhaupt zählen darf.
Quellen
- BleepingComputer: JadePuffer ransomware used AI agent to automate entire attack
- SecurityWeek: Agentic AI Used to Conduct Ransomware Attack via Langflow
- SecurityWeek: Prompt Injection Attacks Trick AI Agents Into Making Crypto Payments
- Sysdig TRT: JADEPUFFER: Agentic ransomware for automated database extortion
- Zscaler ThreatLabz: Indirect Prompt Injection in Web Content Targets AI Agents