Prompt-Injection ist ein architektonisches Risiko: ASD-Analyse

Der beängstigendste Satz in der KI-Sicherheit wird nicht von einem Angreifer im Kapuzenpulli getippt. Er wird von einer Aufsichtsbehörde getippt, ruhig, in der Sprache von Leitlinien: Das lässt sich nicht im Modell beheben. Irgendwo hat gerade ein Prompt Engineer Kaffee über eine laminierte Liste magischer Wörter verschüttet. Genau das ist der nützliche Punkt an der neuen Einordnung von Prompt Injection für agentische KI durch das Australian Signals Directorate. ASD behandelt Prompt Injection nicht wie einen wackeligen Unit-Test, also wie einen weiteren Bug, der vor dem Demo-Tag beseitigt werden muss. Es zeigt auf die Form des Systems selbst, was viel weniger beruhigend und viel besser umsetzbar ist.

ASD verlagert die Lösung aus dem Modell heraus

Laut iTnews hat ASD neue Leitlinien für Unternehmen veröffentlicht, denen zufolge eine zentrale Sicherheitsschwäche in agentischer KI nicht im Modell behoben werden kann. Die Empfehlung der Behörde, wie iTnews berichtet, lautet, dass die Risikominderung in die Softwareschicht gehört, die um Modelle herum gebaut ist. InfoSec Today fasste denselben Kernpunkt so zusammen: Die Schwäche ist nichts, was Modellinterna dauerhaft beseitigen können. Entwickler brauchen daher Kontrollen rund um das Modell statt heldenhafter Prompt-Beschwörungen.

Das ist wichtig, weil das Risiko steigt, wenn LLMs mit Tools, Datenspeichern und Workflow-Aktionen verbunden werden. Ein Chatbot, der ein schlechtes Haiku schreibt, ist peinlich. Ein Agent, der feindliche Anweisungen aus einem Dokument liest und dann ein genehmigtes Tool mit zu weitreichenden Berechtigungen nutzt, ist ein Roomba mit Firmenkreditkarte.

Warum klügeres Prompting an Grenzen stößt

Alexander Arvidssons Analyse bei ArcticDBA erklärt das architektonische Problem in einfachen Worten: System-Prompts, Nutzernachrichten und abgerufene Dokumente fließen alle als Tokens durch dasselbe Kontextfenster. Anders gesagt: Das Modell erhält Anweisungen und potenziell feindliche Inhalte über denselben allgemeinen Kanal. Das ist weniger wie ein abschließbarer Aktenschrank und mehr wie das Passwort auf einen Klebezettel zu schreiben und den Klebezettel dann zu bitten, sich ethisch zu verhalten.

Nilesh Barla von Adaline ergänzt dazu, dass Prompt Injection nicht durch bessere Prompts behoben wird, weil die Angriffsfläche in der Tool-Schicht liegt. Arun Babys Analyse argumentiert ähnlich, dass Filter nicht ausreichen, weil LLMs vertrauenswürdige Anweisungen und nicht vertrauenswürdige Daten durch denselben Token-Strom verarbeiten. Die stärkeren Abwehrmaßnahmen, die Arun Baby nennt, sind architektonischer Art, darunter Privilegientrennung, typgesteuerte Isolation und Spotlighting.

An diesem Punkt wird das Gespräch erfreulicherweise weniger mystisch. Die praktische Lehre lautet nicht: Hört auf, Agenten zu verwenden. Sie lautet: Hört auf so zu tun, als wäre ein längerer System-Prompt Sicherheitsgurt, Airbag und Verkehrsrecht zugleich.

Die Forschung bewegt sich in Richtung Eindämmung

Ciphers Security berichtete, dass ein am 17. Mai 2026 von Sahar Abdelnabi und Eugene Bagdasarian bei arXiv eingereichtes Paper untersucht, warum KI-Agenten möglicherweise immer anfällig für Prompt Injections bleiben. Das arXiv-Paper AI Agents May Always Fall for Prompt Injections sagt, dass bestehende Abwehrmaßnahmen zur Trennung von Daten und Anweisungen kontextuelle Manipulation übersehen und außerdem kontextuell angemessenes Verhalten verschlechtern können.

Das ist der elende Zielkonflikt: Zieht man die Regeln zu eng, bricht nützliche Arbeit zusammen; lockert man sie, kann ein Gegner einen schlechten Ablauf legitim aussehen lassen. Das ist kein brandneuer Kobold, der gestern aus dem GPU-Rack gekrochen ist. Das ältere arXiv-Paper Prompt Injection: Parameterization of Fixed Inputs zeigt, dass das Problem seit Jahren eine formale Forschungsspur hat. Wenn ein Anbieter-Pitch Prompt Injection als neu entdeckte Unannehmlichkeit darstellt, die durch proprietären Feenstaub gelöst wird, prüfen Sie erst die Bibliografie, bevor Sie die Rechnung prüfen.

Das arXiv-Paper von 2026 rahmt das Problem über Contextual Integrity neu, eine Datenschutztheorie darüber, ob Informationsflüsse kontextuellen Normen entsprechen. Diese Einordnung ist hilfreich, weil Agenten Entscheidungen zunehmend auf Grundlage von Kontext treffen, nicht nur anhand statischer Zeichenketten. Das Schwierige ist nicht, die Formulierung „ignoriere frühere Anweisungen“ zu erkennen, sondern zu merken, wann eine scheinbar vernünftige Anfrage die falsche Autorität, den falschen Zweck oder den falschen Ablauf einschmuggelt.

Was Entwickler jetzt tun sollten

Zusammengenommen weisen die ASD-Leitlinien über iTnews und die Forschungsliteratur in Richtung Eindämmung. Geben Sie Agenten nur den Tool-Zugriff, den sie wirklich brauchen, trennen Sie vertrauenswürdige Anweisungen so weit wie architektonisch möglich von nicht vertrauenswürdigen Inhalten, verlangen Sie menschliche Prüfung für Maßnahmen mit hoher Auswirkung und überwachen Sie die Tool-Nutzung, als gehöre sie einem sehr eifrigen Junior-Mitarbeiter. Nicht weil der Junior-Mitarbeiter böse ist, sondern weil er überzeugt werden kann, dass der Fotokopierer eine Strategie zur Datenbankmigration ist.

Für Produktteams lautet die unmittelbare Frage nicht, ob ein LLM vollkommen gehorsam gemacht werden kann. Sie lautet, was passiert, wenn es das nicht ist. Entwerfen Sie Systeme so, dass eine schlechte Anweisung auf Berechtigungsgrenzen, Protokollierung, Prüfschleusen und eng begrenzte Tools trifft, bevor sie Geld, Kundendaten oder Produktions-Workflows berührt.

Für Leserinnen und Leser, die mit Agenten bauen, ist ASDs Warnung ein Schubs weg vom Prompt-Aberglauben und hin zu Security Engineering. Das Modell ist nicht die Burg. Es ist der sehr überzeugende Praktikant, der die Schlüssel hält.