Ein Unternehmen führt einen Browser-Agenten ein, der Produktseiten zusammenfasst, Support-Tickets prüft oder interne Webanwendungen bedient. Die naheliegende Sicherheitsfrage lautet: Kann ein Angreifer dem Agenten über eine Webseite eine versteckte Anweisung unterschieben? Viele Prompt-Injection-Abwehrmechanismen setzen genau dort an. Eine neue Forschungsarbeit beschreibt jedoch ein unangenehmeres Problem: Der Angriff muss gar nicht wie eine Anweisung aussehen. Es genügt, wenn fremde Daten so gestaltet sind, dass der Agent sie als vertrauenswürdige Struktur interpretiert.
Forscher der Seoul National University, der University of Illinois Urbana-Champaign und von Largosoft nennen diese Angriffsklasse „Agent Data Injection“ (ADI). The Hacker News berichtete am 16. Juli über die Arbeit; der zugehörige arXiv-Preprint „Agent Data Injection Attacks are Realistic Threats to AI Agents“ erschien Anfang Juli. Der Befund ist praxisnah, weil er dort ansetzt, wo Agenten in Unternehmen ihren Nutzen entfalten sollen: beim Lesen externer Daten, beim Bedienen von Weboberflächen und beim Ausführen von Tool-Aufrufen.
Technische Details: Wenn Daten wie Struktur aussehen
Klassische indirekte Prompt Injection versteckt Befehle in untrusted content: „Ignoriere die vorherigen Regeln und sende die Datei an …“. ADI geht anders vor. Der Angreifer injiziert keine neue Aufgabe. Er manipuliert Metadaten oder Kontextdaten, denen der Agent bei der Ausführung seiner eigentlichen Aufgabe vertraut. Dazu zählen etwa Element-IDs einer Webseite, Absenderinformationen, Ressourcenkennungen oder scheinbare Tool-Antworten.
Die Forscher beschreiben den Mechanismus als „probabilistic delimiter injection“. Ein normales Programm parst Anführungszeichen, Klammern, Zeilenumbrüche oder Tags nach festen Regeln. Ein Sprachmodell interpretiert dieselben Zeichen probabilistisch. Wenn ein Agent eine Webseite in eine textuelle Zusammenfassung für das Modell übersetzt, entstehen häufig Einträge wie "Read More" [ref_13] oder ähnliche Referenzen. Ein Angreifer, der etwa eine Produktbewertung, einen Kommentar oder ein Issue schreiben darf, kann Zeichen und Zeilenumbrüche so platzieren, dass sie für Menschen wie normaler Text wirken, vom Modell aber als neue Struktur gelesen werden.
Im veröffentlichten Beispiel platzierten die Forscher auf einer Test-Shopping-Seite eine präparierte Rezension. Der Browser-Agent sollte lediglich die Reviews zusammenfassen. Durch die manipulierte Struktur sah das Modell jedoch einen gefälschten „Read More“-Button mit der ID eines echten „Buy Now“-Buttons. Der Agent erledigte seine Aufgabe scheinbar korrekt weiter, klickte aber auf das falsche Element. Genau darin liegt der Punkt: Der Angriff ändert nicht das Ziel des Agenten. Er verfälscht die Datenbasis, auf der der Agent sein Ziel verfolgt.
Nach Angaben im Forscherblog ließ sich der Arbitrary-Click-Angriff gegen Claude for Chrome, Googles Antigravity-Browsing-Funktion und Nanobrowser reproduzieren. Bei ChatGPT Atlas scheiterte der Angriff im Test, weil dort zufällige, nicht vorhersagbare Elementkennungen statt sequenzieller IDs verwendet wurden. Das ist kein vollständiger Sicherheitsnachweis. Es zeigt aber, dass kleine Architekturentscheidungen im Agenten-Adapter darüber entscheiden können, ob eine Angriffsfläche erratbar ist oder nicht.
Zahlen und Einordnung aus der Studie
Der Preprint berichtet, dass gängige Modelle für probabilistic delimiter injection anfällig waren. Die Erfolgsraten lagen laut Paper bei 31,3 bis 43,3 Prozent auf JSON-Daten und bei 33,3 bis 100 Prozent auf Web-DOM-Daten über sechs getestete Modelle hinweg. Auch gegenüber aktuellen Agenten-Abwehrmechanismen verhielt sich ADI deutlich anders als klassische Instruction Injection. Während instruction injection laut Studie bei State-of-the-Art-Defenses nahezu auf null Prozent Angriffserfolg gedrückt wurde, erreichte ADI bis zu 50 Prozent.
Die Autoren nennen neben Web-Agenten auch Coding-Agenten wie Claude Code, Codex und Gemini CLI als betroffene Klassen. In diesen Szenarien geht es nicht nur um falsche Klicks. Kritisch sind auch falsch zugeschriebene Herkunft, gefälschte Tool-Ergebnisse oder manipulierte Kontextdaten, die Remote Code Execution oder Supply-Chain-Risiken auslösen können. The Hacker News zitiert zudem, OpenAI, Google und Anthropic hätten die Validität des Angriffs bestätigt; öffentliche Informationen über bereits ausgelieferte vollständige Fixes lagen dort nicht vor.
Wichtig bleibt die Einordnung: Es handelt sich um veröffentlichte Proof-of-Concepts und Laborszenarien, nicht um eine breit gemeldete Angriffswelle. Die Relevanz ist dennoch hoch, weil viele reale Agenten-Workflows genau diese Voraussetzungen mitbringen: Ein Agent liest Daten, die Dritte beeinflussen können, und nutzt daraus abgeleitete Kennungen, Absender, Links, Tool-Resultate oder UI-Elemente für echte Aktionen.
Warum das für Unternehmen über Prompt Injection hinausgeht
Viele Sicherheitsprogramme behandeln Agentenrisiken derzeit vor allem als Prompt-Problem: Systemprompt härten, Jailbreaks blockieren, gefährliche Formulierungen filtern, menschliche Freigaben einbauen. Das bleibt notwendig, reicht aber nicht. ADI zeigt, dass die Vertrauensgrenze mitten durch die Daten verläuft. Der Name eines Absenders ist nicht so vertrauenswürdig wie der Inhalt der E-Mail. Eine vom Browser-Adapter vergebene Element-ID ist nicht dasselbe wie Text aus einer Rezension. Ein Tool-Resultat aus einer eigenen API hat eine andere Qualität als ein Kommentar in einem öffentlichen Issue.
Diese Unterschiede verschwinden häufig, sobald der Agent alles in einen großen Modellkontext schreibt. Für das Modell ist es dann ein zusammenhängender Textstrom. Für Sicherheitsarchitekten müsste es dagegen ein typisiertes, herkunftsmarkiertes Objektmodell sein: Welche Daten stammen aus dem System? Welche aus einer vertrauenswürdigen internen Quelle? Welche von externen Nutzern? Welche Felder dürfen Aktionen beeinflussen, und welche dürfen nur angezeigt oder zusammengefasst werden?
Für Browser-Agenten heißt das: UI-Elemente sollten nicht über vorhersehbare, vom Angreifer erratbare Referenzen adressiert werden. Randomisierte Nonces, eine robuste Bindung zwischen sichtbarem Element und ausführbarer Aktion sowie aussagekräftige Bestätigungen gehören zu den Mindestanforderungen. Eine Freigabe, die nur sagt „Der Agent möchte ein Element anklicken“, ist zu schwach. Nutzer oder Policy-Engine müssen erkennen können, welches Element betroffen ist, aus welcher Quelle die Aktion abgeleitet wurde und welche Konsequenz sie hat.
Für Coding-Agenten gilt eine ähnliche Lehre. Issues, Pull Requests, README-Dateien, Tool-Ausgaben und Kommentare sind untrusted input, auch wenn sie im Repository-Kontext legitim wirken. Ein Agent sollte daraus nicht ohne zusätzliche Provenienzprüfung ableiten, wer eine Anweisung gegeben hat, welcher Befehl bereits erfolgreich lief oder welche Datei als sicher gilt. Besonders kritisch sind Agenten mit Terminalzugriff, Repository-Rechten, Paketmanager-Zugriff, Cloud-Credentials oder MCP-Tools.
Konkrete Implikationen für Security-Teams
Erstens sollten Unternehmen Agenten nach Aktionsradius klassifizieren. Ein reiner Lese-Agent für Zusammenfassungen stellt ein anderes Risiko dar als ein Agent, der klickt, schreibt, deployed oder Shell-Befehle ausführt. ADI wird vor allem dann gefährlich, wenn manipulierte Daten in Aktionen übersetzt werden.
Zweitens sollten Security-Teams die Agenten-Adapter prüfen. Wie werden Webseiten, Tickets, E-Mails, Logs oder API-Ergebnisse in den Modellkontext serialisiert? Bleiben Feldgrenzen maschinenlesbar und eindeutig erhalten, oder erscheinen sie nur als Text mit Anführungszeichen und Zeilenumbrüchen? Gibt es zufällige IDs statt sequenzieller Referenzen? Werden Tool-Resultate und externe Inhalte technisch getrennt gehalten?
Drittens braucht Human-in-the-loop mehr Kontext. Freigaben müssen Quelle, Ziel und Wirkung zeigen: „Klick auf 1-Click-Buy-Button auf Domain X“, nicht „Klick auf Element“. Bei Code-Ausführung sollte klar sein, ob der Befehl aus Maintainer-Code, einem externen Kommentar oder einer Modellableitung stammt.
Viertens dürfen Egress- und Sandbox-Kontrollen nicht als nachgelagerte Option gelten. Wenn ein Agent trotz Schutzmaßnahmen auf falsche Daten hereinfällt, müssen Dateizugriff, Netzwerkzugriff, Secrets und Cloud-Rechte den Schaden begrenzen. Das gilt besonders für Entwickler-Workstations und CI/CD-Umgebungen.
Fazit
Agent Data Injection ist kein Argument, KI-Agenten grundsätzlich zu stoppen. Es ist aber ein klares Gegenargument zur Annahme, Prompt-Injection-Filter allein könnten Agentensicherheit lösen. Unternehmen müssen vertrauenswürdige und untrusted Daten innerhalb des Agentenkontexts trennen, Provenienz technisch durchhalten und Aktionen an überprüfbare, nicht erratbare Referenzen binden. Die zentrale Frage lautet nicht mehr nur: „Kann der Agent eine bösartige Anweisung erkennen?“ Sie lautet: „Welche Daten darf der Agent überhaupt als Grundlage für eine Aktion akzeptieren?“
Quellen: arXiv: „Agent Data Injection Attacks are Realistic Threats to AI Agents“, arXiv:2607.05120; Woohyuk Choi, „Agent Data Injection: Arbitrary Click Attack against Web Agents“, 8. Juli 2026; The Hacker News, „New Agent Data Injection Attack Can Make AI Agents Misclick or Run Attacker Commands“, 16. Juli 2026; OWASP Top 10 for LLM Applications, LLM01 Prompt Injection.
