KI-Agent-Frameworks machen Prompt Injection zu einem Sicherheitsversagen

Google News hat diese Woche ein unverblümtes Sicherheitsargument hervorgehoben: Prompt Injection ist trotz jahrelanger darauf ausgerichteter Abwehrmaßnahmen nicht der grundlegende Fehler. Das tiefere Versagen liegt in KI-Agent-Frameworks, die unsichere Modellausgaben in privilegierte Aktionen verwandeln.

Diese Unterscheidung verändert, was Entwicklungsteams absichern müssen. Ein manipulierter Chatbot kann Unsinn erzeugen. Ein manipulierter Agent kann private Dateien lesen, APIs aufrufen, Code verändern, Nachrichten senden oder gemeinsamen Speicher kontaminieren.

Die Einordnung von The Register stellt eine vertraute Annahme infrage. Entwickler behandeln bösartigen Text häufig als Schwachstelle und stärkere Prompts als Gegenmaßnahme. Die folgenreichere Frage ist, was das umgebende System zulässt, nachdem das Modell diesen Text akzeptiert hat.

Dies ist kein Argument dafür, dass Prompt Injection harmlos sei. Sie bleibt ein zuverlässiger Weg, Modelle durch direkte Anfragen oder nicht vertrauenswürdige externe Inhalte zu beeinflussen. Zu einem operativen Sicherheitsvorfall wird die Injection jedoch erst, wenn die Architektur Autorität, Daten und einen ausführbaren Pfad bereitstellt.

Der sich abzeichnende Gegensatz ist daher klar. Die eine Seite verlässt sich darauf, dass Modelle gefährliche Anweisungen in mehrdeutiger Sprache erkennen. Die andere geht davon aus, dass diese Erkennung letztlich scheitern wird, und begrenzt, was ein kompromittiertes Modell überhaupt ausführen kann.

Google News rückt das Agent-Framework ins Zentrum

Die entscheidende Veränderung ist eine Verlagerung der Verantwortung vom Modellverhalten zur Systemarchitektur.

Prompt Injection wurde gewöhnlich als Sicherheitsproblem von Modellen beschrieben. Ein Angreifer platziert Anweisungen in einem Prompt, Dokument, auf einer Website, in einer E-Mail, einem Bild oder einer Tool-Antwort. Das Modell befolgt dann diese Anweisungen statt der eigentlichen Anfrage des Nutzers.

Diese Beschreibung ist zutreffend, aber unvollständig. Sie benennt die Methode zur Beeinflussung des Modells, nicht jedoch den Kontrollfehler, der echten Schaden verursacht. Nicht vertrauenswürdiger Text kann nicht eigenständig eine Datei löschen, einen Kundendatensatz abrufen oder Quellcode veröffentlichen.

Ein Agent-Framework stellt diese Fähigkeiten bereit. Es verbindet ein Modell mit Tools, Zugangsdaten, Speicher, Datenbanken, Browsern, Code-Interpretern und anderen Agenten. Es kann außerdem entscheiden, ob das Modell ohne erneute menschliche Autorisierung handeln darf.

Die Architektur kann aus einer einzigen Fehlinterpretation eine Abfolge von Nebenwirkungen machen. Eine manipulierte Webseite wird zu einer Tool-Anfrage. Die Tool-Anfrage wird zu einer Datenbankabfrage. Das abgerufene Material erscheint anschließend in einer vom selben Agenten erzeugten ausgehenden Nachricht.

Indirekte Prompt Injection ist hier besonders wichtig. Der Angreifer benötigt keinen Zugriff auf die Chat-Oberfläche. Bösartige Anweisungen können in Inhalten warten, auf die der Agent während einer gewöhnlichen Aufgabe stößt.

Ein Recherche-Agent könnte den Anweisungen auf einer Webseite begegnen. Ein Coding-Assistent könnte sie in einer Issue-Beschreibung oder Repository-Datei finden. Ein Büro-Agent könnte sie aus einer E-Mail, Kalendereinladung oder einem geteilten Dokument aufnehmen.

Das Modell steht in jedem Fall vor einem schwierigen Klassifikationsproblem. Es muss Text, der eine Anweisung beschreibt, von Text unterscheiden, dem es folgen soll. Beides trifft als Tokens natürlicher Sprache im Arbeitskontext des Modells ein.

Die OWASP-Risikodefinition erkennt sowohl direkte als auch indirekte Injection an. Sie weist zudem darauf hin, dass die Auswirkungen stark vom Geschäftskontext und von der dem Modell eingeräumten Handlungsfähigkeit abhängen.

Diese letzte Bedingung ist wichtiger, als sie zunächst erscheint. Derselbe bösartige Satz kann in zwei Bereitstellungen völlig unterschiedliche Folgen haben. Ein schreibgeschützter Zusammenfasser könnte einen verfälschten Absatz erzeugen, während ein privilegierter Agent vertrauliche Informationen preisgeben könnte.

Google News ist für diese Debatte als Entdeckungskanal nützlich, aber keine grundlegende Autorität. Die Überschrift verweist auf ein breiteres Feld an Sicherheitsarbeit, das die Übernahme von Agenten zunehmend als architektonische Bedrohung behandelt.

NIST beschreibt Agent Hijacking als indirekte Prompt Injection, die einen Agenten zu unbeabsichtigten schädlichen Aktionen veranlasst. Seine Hijacking-Evaluierungen nutzen simulierte Arbeitsbereiche, Reisedienste, Nachrichtensysteme und Banking-Tools.

Diese Umgebungen zeigen, warum sich Agentensicherheit von Chatbot-Sicherheit unterscheidet. Das Modell beantwortet nicht bloß eine Frage. Es wählt Aktionen innerhalb eines Workflows aus, der Berechtigungen und reale Konsequenzen mit sich bringt.

Diese Neuformulierung schärft auch die Schwachstellenberichterstattung. „Prompt Injection“ beschreibt, wie die Beeinflussung in das System gelangte. Ein hilfreicher Sicherheitsbefund sollte auch die daraus resultierende Auswirkung benennen, etwa unbefugten Datenzugriff oder nicht genehmigte Codeausführung.

Traditionelle Sicherheitsteams treffen bereits ähnliche Unterscheidungen. Nutzergesteuerte Eingaben sind nicht automatisch ein Sicherheitsvorfall. Die Schwachstelle entsteht, wenn Software diese Eingabe an einen unsicheren Interpreter weitergibt oder ihr über eine Sicherheitsgrenze hinweg vertraut.

Sprachmodelle erschweren die Analogie, weil Anweisungen und Daten dieselbe flexible Darstellung teilen. Für jede Aufgabe in natürlicher Sprache gibt es kein universelles Gegenstück zu einer parametrisierten Datenbankabfrage. Umso wichtiger wird die Eindämmung rund um das Modell.

Das zentrale Ereignis ist daher konzeptionell, aber operativ bedeutsam. Die Sicherheitsarbeit entfernt sich von Versprechen perfekter Anweisungsfilterung. Sie bewegt sich hin zu Grenzen, die auch dann wirksam bleiben, wenn das Modell die falsche Entscheidung trifft.

Prompt Injection ist der Auslöser, nicht der Schadensradius

Eine eingeschleuste Anweisung schafft Einfluss, während das Framework bestimmt, ob dieser Einfluss zu einem Sicherheitsvorfall wird.

Betrachten wir einen Agenten, der eingehende Support-Tickets prüfen soll. Er benötigt Zugriff auf Tickettexte, Kundendetails und möglicherweise eine interne Wissensdatenbank. Eventuell verfügt er auch über Tools zur Erstattung von Zahlungen oder zum Versenden von Kontonachrichten.

Ein Angreifer platziert eine versteckte Anweisung in einem Ticket. Die Anweisung fordert den Agenten auf, den Datensatz eines anderen Kunden abzurufen und ihn in eine Antwort aufzunehmen. Das Modell folgt dieser Anweisung, während es glaubt, seinen zugewiesenen Workflow auszuführen.

Bevor Daten das Unternehmen verlassen, müssen mehrere Fehler auftreten. Der Agent muss weitergehenden Zugriff erhalten, als das aktuelle Ticket erfordert. Seine Tool-Schicht muss modellgenerierte Parameter akzeptieren. Die ausgehende Aktion muss ohne unabhängige Autorisierung fortgesetzt werden.

Der bösartige Text hat die Kette ausgelöst. Er hat weder die übermäßigen Berechtigungen noch die fehlenden Datengrenzen oder das nicht vorhandene Freigabegate geschaffen. Diese Entscheidungen stammten aus der Anwendung und dem Framework.

Diese Unterscheidung ist zentral für die Sicherheit von KI-Agenten. Ein System sollte davon ausgehen, dass das Urteilsvermögen des Modells fehleranfällig ist, insbesondere wenn es von Angreifern kontrollierte Inhalte verarbeitet. Sicherheitskontrollen müssen außerhalb dieser Urteilsschleife bleiben.

Tool-Schemas allein lösen das Problem nicht. Ein Schema kann eine gültige E-Mail-Adresse oder Dokumentkennung verlangen. Es kann nicht bestimmen, ob das Modell einen legitimen Grund hat, diese Adresse zu kontaktieren oder dieses Dokument abzurufen.

Eine wohlgeformte bösartige Aktion bleibt bösartig. Das Framework benötigt eine Durchsetzung von Richtlinien, die an Nutzeridentität, Dateneigentum, Aufgabenbereich, Herkunft und aktuellen Autorisierungsstatus gebunden ist.

Herkunft bedeutet, festzuhalten, woher Informationen stammen, und diese Kennzeichnung im gesamten Workflow zu bewahren. Inhalte von einer unbekannten Webseite sollten keinen vertrauenswürdigen Status erhalten, nur weil ein Agent sie zusammengefasst hat.

Diese Regel wird in Multi-Agenten-Systemen schwieriger. Ein Modell könnte ein Thema recherchieren, ein anderes eine Antwort planen und ein drittes Tools ausführen. Bösartige Anweisungen können verändert werden, während Ausgaben zwischen ihnen weitergereicht werden.

Der empfangende Agent sieht möglicherweise ausgefeilte Prosa, ohne die nicht vertrauenswürdige Quelle zu sehen, die sie beeinflusst hat. Wenn das Framework die Herkunft verwirft, kann das Waschen der Anweisung durch einen anderen Agenten ihre Autorität effektiv erhöhen.

Persistenter Speicher schafft einen weiteren Pfad. Ein Angreifer kann einen Agenten dazu bringen, eine schädliche Regel, falsche Tatsache oder veränderte Präferenz zu speichern. Spätere Sitzungen können diesen Eintrag abrufen, nachdem die ursprünglichen bösartigen Inhalte verschwunden sind.

Teams, die eine persönliche Wissensdatenbank aufbauen, stehen vor einer verwandten Vertrauensfrage. Abgerufene Informationen sollten ihre Quellen- und Zugriffskontexte behalten, insbesondere wenn ein Agent auf ihrer Grundlage handeln kann.

Speicher sollte nicht zu einer unsichtbaren Steuerungsebene werden. Schreiboperationen benötigen Einschränkungen, Prüfprotokolle und eine klare Trennung zwischen vom Nutzer genehmigten Präferenzen und modellgenerierten Beobachtungen.

Das Browsen bringt eigene Risiken mit sich. Eine Seite kann sichtbare Anweisungen, versteckten Text, Metadaten, Bildinhalte oder gegnerisches Material enthalten, das für ein Modell statt für einen Menschen bestimmt ist. Der Agent verarbeitet diese Inhalte, weil das Browsen seine vorgesehene Funktion ist.

Google berichtete, das öffentliche Web auf bekannte indirekte Injection-Muster zu überwachen. Seine Forschung zu Webbedrohungen behandelte diese Muster als Priorität, weil Browser-Agenten routinemäßig von Angreifern kontrollierte Seiten konsumieren.

Daraus ergibt sich ein struktureller Zielkonflikt. Je breiter der Informationszugriff eines Agenten wird, desto mehr nicht vertrauenswürdigen Inhalten begegnet er. Je mehr Autorität er erhält, desto größer sind die möglichen Auswirkungen einer einzigen Fehlinterpretation.

Die vollständige Eliminierung externer Inhalte würde viele Agenten nutzlos machen. Allen externen Inhalten den gleichen Einfluss zu geben, macht sie unsicher. Frameworks müssen den Nutzen erhalten und zugleich Grenzen durchsetzen, die Sprache allein nicht garantieren kann.

Das bedeutet, Planung von Autorisierung zu trennen. Ein Modell kann eine Aktion vorschlagen, ihre Begründung erläutern und Parameter vorbereiten. Ein deterministischer Richtliniendienst sollte entscheiden, ob die Aktion zulässig ist.

Die Entscheidung sollte den aktuellen Nutzer, die angeforderte Aufgabe, die Zielressource, die Datensensibilität und die Herkunft der Inhalte berücksichtigen. Aktionen mit hoher Auswirkung sollten eine Bestätigung erfordern, die klar zeigt, was passieren wird.

Die Bestätigung darf nicht vollständig vom potenziell kompromittierten Modell verfasst werden. Andernfalls kann ein Angreifer sowohl die vorgeschlagene Aktion als auch die dem Nutzer angezeigte Beschreibung beeinflussen.

Eine vertrauenswürdige Oberfläche sollte kritische Details aus validierten Tool-Parametern erstellen. Sie sollte das Ziel, betroffene Datensätze, angeforderte Berechtigungen und alle Daten benennen, die das System verlassen sollen.

So wird der Schadensradius messbar. Selbst wenn Prompt Injection auf der Sprachebene erfolgreich ist, trifft der Angreifer an jeder folgenreichen Grenze auf separate Kontrollen.

Das Ergebnis ähnelt ausgereifter Anwendungssicherheit mehr als ausgeklügeltem Prompt Engineering. Least Privilege, Isolation, explizite Autorisierung, Ausgabevalidierung, Protokollierung und Incident Response bleiben unverzichtbar.

Warum stärkere System-Prompts die Sicherheitsgrenze nicht tragen können

Prompt-Härtung reduziert erfolgreiche Angriffe, doch verbleibende Fehler machen sie als endgültige Autorisierungsebene ungeeignet.

System-Prompts können einem Agenten vorgeben, Anweisungen in externen Inhalten zu ignorieren. Sie können Quellenmaterial als nicht vertrauenswürdig kennzeichnen und das Modell daran erinnern, nur dem Ziel des Nutzers zu folgen.

Diese Maßnahmen sind sinnvoll. Sie können einfache Angriffe blockieren, unbeabsichtigte Abweichungen verringern und Angreifer zu größerem Aufwand zwingen. Außerdem helfen sie Modellen dabei, verdächtige Inhalte zu erklären, statt unmittelbar darauf zu reagieren.

Google-Forschende testeten Sicherheits-Prompting in einem Multi-Agenten-Framework für Programmierung. Ihre Multi-Agenten-Studie umfasste mehr als 150 Single-Turn- und 32 Multi-Turn-Angriffsszenarien.

Ein Sicherheits-Hardener mit rund 500 Token senkte die Single-Turn-Fehlerraten von 19,48 Prozent auf 2,60 Prozent. Die Multi-Turn-Fehlerraten fielen von 75 Prozent auf 46,88 Prozent.

Diese Ergebnisse sprechen für Prompt-Härtung, legen aber zugleich ihre Grenze offen. Eine Multi-Turn-Fehlerrate von 46,88 Prozent bleibt inakzeptabel, wenn der Agent Code ausführen, auf Zugangsdaten zugreifen oder Produktionsressourcen verändern kann.

Selbst die niedrigere Single-Turn-Rate schafft im großen Maßstab ein erhebliches Risiko. Wiederholte Interaktionen eröffnen Angreifern zusätzliche Chancen, und sie können ihre Formulierungen anpassen, nachdem sie das Modellverhalten beobachtet haben.

Die Studie stellte zudem fest, dass sich erfolgreiche Angriffe in Richtung funktionaler Wrapper verlagerten. Diese Angriffe verbergen schädliche Absichten in Aufgaben, die gewöhnlichen Agentenfunktionen ähneln. Statische Anweisungen können sie nur schwer zurückweisen, ohne zugleich legitime Arbeit zu blockieren.

Das ist das Kernproblem, wenn die Sicherheitsgrenze innerhalb des Modells liegt. Das Modell muss eine offene Anfrage interpretieren und gleichzeitig vorhersagen, ob sie gegen eine andere offene Anweisung verstößt.

Es bewertet keine stabile Berechtigungsregel, wie ein Betriebssystem den Dateizugriff prüft. Stattdessen erzeugt es eine probabilistische Antwort, die von jedem relevanten Token in seinem Kontext beeinflusst wird.

Prompt Injection nur als „Ignorieren vorheriger Anweisungen“ zu erklären, verfehlt diese Mehrdeutigkeit. Wirksame Angriffe kündigen einen Konflikt nicht immer an. Sie können falschen Kontext präsentieren, Sprache vertrauenswürdiger Workflows imitieren oder ihre Absicht auf mehrere Schritte verteilen.

Ein Agent zur Codeprüfung könnte auf Text stoßen, der einen erforderlichen Test zu beschreiben scheint. Der Test lädt im Hintergrund eine externe Komponente herunter oder führt sie aus. Jeder einzelne Schritt kann innerhalb eines Entwicklungsworkflows plausibel wirken.

Einem Browser-Agenten könnte mitgeteilt werden, dass eine bestimmte Aktion erforderlich sei, um auf die angeforderte Seite zuzugreifen. Ein Office-Assistent könnte ein Dokument lesen, in dem behauptet wird, die Unternehmensrichtlinie verlange die Weiterleitung von Inhalten zur Compliance-Prüfung.

Dem Modell fehlt unabhängiges Wissen über die tatsächlichen Richtlinien jeder Organisation. Wenn das Framework zulässt, dass vom Modell erzeugte Behauptungen vom Modell erzeugte Aktionen autorisieren, wird das System zirkulär.

Filter stoßen auf eine ähnliche Grenze. Ein Detektor kann nach bekannten Formulierungen suchen oder einschätzen, ob Text wie ein Angriff aussieht. Angreifer können Anweisungen umformulieren, Nutzlasten aufteilen, sie über verschiedene Formate hinweg verstecken oder sie normalen Daten ähneln lassen.

Jeden Imperativsatz zu blockieren, würde gängige Workflows zerstören. Dokumente, E-Mails, Code-Kommentare und Support-Tickets enthalten legitimerweise Anweisungen. Der Agent muss diese Anweisungen oft verstehen, ohne sie als eigene Ziele zu übernehmen.

Fine-Tuning kann die Widerstandsfähigkeit verbessern, beseitigt den architektonischen Konflikt jedoch nicht. Modelle müssen weiterhin nicht vertrauenswürdige Sprache interpretieren, und neue Angriffsmuster können außerhalb ihrer Trainingsverteilung liegen.

Retrieval-augmented Generation beseitigt den Konflikt ebenfalls nicht. RAG ruft externes Material ab und fügt es dem Kontext des Modells hinzu. Wenn die Quelle vergiftet ist, kann das Retrieval die Anweisung des Angreifers genau dann liefern, wenn sie relevant erscheint.

Modell-Upgrades können das Risiko sogar unerwartet verändern. Ein leistungsfähigeres Modell erkennt Angriffe möglicherweise besser, könnte nach einem erfolgreichen Angriff aber auch Tools effektiver einsetzen.

Deshalb benötigen Benchmark-Ergebnisse Kontext. Ein Modell, das in einer festen Testsuite die meisten Injections zurückweist, hat nicht nachgewiesen, dass ein eingesetzter Agent sicher ist. Reale Systeme enthalten individuelle Tools, Berechtigungen, Speicher und Integrationen.

Das Verteidigungsziel sollte ein kontrolliertes Scheitern sein. Wenn das Modell Inhalte falsch klassifiziert, sollte das umgebende System die Folgen begrenzen, den Versuch sichtbar machen und Belege für die Prüfung bewahren.

Ein schreibgeschützter Agent kann Nutzerinnen und Nutzer weiterhin in die Irre führen, daher bleibt die Ausgabequalität wichtig. Die schwerwiegendsten Folgen entstehen jedoch meist, wenn Frameworks unsicheres Schlussfolgern mit unbegrenzter Autorität verbinden.

Sicherheits-Prompts gehören daher in ein mehrschichtiges Design. Sie sind eine Kontrolle, aber nicht die Kontrolle, die entscheidet, ob private Daten eine Grenze überschreiten oder ausführbarer Code einen Arbeitsplatzrechner erreicht.

Die Sicherheit von KI-Agenten hängt von Fähigkeiten, Kontext und Einwilligung ab

Frameworks sollten das Modell als nicht vertrauenswürdigen Planer behandeln, dessen Vorschläge durchsetzbare Prüfungen erfordern.

Die erste architektonische Kontrolle ist die Minimierung von Fähigkeiten. Ein Agent sollte nur die Tools erhalten, die für die aktuelle Aufgabe erforderlich sind, und nicht jede Integration, die Nutzenden oder der Organisation zur Verfügung steht.

Ein Kalender-Zusammenfasser benötigt selten die Berechtigung, E-Mails zu versenden. Ein Rechercheassistent braucht nicht automatisch Shell-Zugriff. Ein Code-Reviewer könnte Lesezugriff auf ein Repository benötigen, ohne Änderungen zusammenführen zu dürfen.

Statisches Least Privilege ist hilfreich, aber aufgabenspezifische Freigaben sind besser. Ein Tool kann für einen begrenzten Vorgang verfügbar werden und verschwinden, sobald dieser Vorgang endet.

Auch Zugangsdaten sollten außerhalb des Modellkontexts bleiben. Das Modell sollte eine Operation über einen Broker anfordern, statt wiederverwendbare Geheimnisse direkt zu verarbeiten. Protokolle sollten sensible Token aus Prompts und Tool-Antworten schwärzen.

Die zweite Kontrolle ist kontextbezogene Autorisierung. Herkömmliche Zugriffsprüfungen beantworten oft die Frage, ob ein Nutzer auf eine Ressource zugreifen darf. Agentensysteme müssen zusätzlich fragen, ob dieser Zugriff die aktuelle Anfrage des Nutzers unterstützt.

Ein Nutzer, der zwei Kundenkonten lesen darf, hat einen Agenten nicht zwangsläufig dazu autorisiert, sie zusammenzuführen. Ein Entwickler mit Deployment-Zugriff hat nicht jeden Code-Review-Agenten zum Deployen autorisiert.

Absichten lassen sich nicht perfekt aus Sprache ableiten, aber Frameworks können sie durch explizite Aufgabendeklarationen eingrenzen. Sie können Tools an ein erklärtes Ziel, eine Ressourcenmenge, ein Zeitfenster und einen erlaubten Datenfluss binden.

Die dritte Kontrolle ist Einwilligung bei folgenreichen Aktionen. Menschliche Zustimmung ist besonders wichtig, bevor Informationen extern versendet, Geld ausgegeben, Zugriffe verändert, Daten gelöscht oder nicht vertrauenswürdiger Code ausgeführt wird.

Die Einwilligung muss sinnvoll sein. Wiederholte vage Pop-ups trainieren Nutzende darauf, ohne Prüfung zuzustimmen. Die Oberfläche sollte die genaue Aktion benennen und Abweichungen von der ursprünglichen Aufgabe hervorheben.

Risikoarme, reversible Aktionen können mit leichteren Kontrollen auskommen. Risikoreiche oder irreversible Aktionen benötigen eine stärkere Bestätigung und in Unternehmensumgebungen möglicherweise eine zweite Freigabe.

Die vierte Kontrolle ist Isolierung. Codeausführung sollte innerhalb einer Sandbox mit eingeschränktem Netzwerk-, Dateisystem- und Zugangsdatenzugriff erfolgen. Browser-Sitzungen sollten nicht vertrauenswürdige Seiten von sensiblen Anwendungszuständen trennen.

Tool-Ausgaben sollten als Daten und nicht als automatisch vertrauenswürdige Anweisungen behandelt werden. Frameworks sollten Größe, Format, Ziel und zulässige Inhalte der Ausgabe validieren, bevor sie an das Modell zurückgegeben wird.

Die fünfte Kontrolle ist die Bewahrung der Herkunft. Jedes Dokument, jede Nachricht, Webseite, Speicherinformation und Agentenantwort sollte ihre Herkunft und Vertrauensklassifizierung mitführen.

Wenn ein Agent eine nicht vertrauenswürdige Seite zusammenfasst, sollte die Zusammenfassung nicht vertrauenswürdig bleiben. Eine Transformation darf die Herkunftskette nicht auslöschen. Eine nachgelagerte Policy Engine kann dann verhindern, dass Material mit geringem Vertrauen Aktionen mit hoher Auswirkung autorisiert.

Die sechste Kontrolle ist die Trennung zwischen Vorschlag und Ausführung. Ein Planer kann entscheiden, dass eine E-Mail gesendet werden sollte, doch eine separate Komponente sollte Empfänger und Anhänge validieren.

Diese Trennung begrenzt Confused-Deputy-Angriffe. Ein Confused Deputy entsteht, wenn ein System mit legitimer Autorität manipuliert wird, diese Autorität für den Zweck einer anderen Person einzusetzen.

Die siebte Kontrolle ist Beobachtbarkeit. Teams benötigen Aufzeichnungen darüber, welche Quelle eine Entscheidung beeinflusste, welches Modell eine Aktion vorschlug, welche Richtlinie sie erlaubte und welches Tool sie ausführte.

Ohne diese Aufzeichnungen kann eine Organisation einen Agenten-Vorfall nicht rekonstruieren. Gewöhnliche Anwendungsprotokolle erfassen möglicherweise API-Aufrufe, lassen aber den Prompt, abgerufene Inhalte, Speicherzustände und Agent-zu-Agent-Nachrichten aus.

Das Monitoring sollte sich zudem auf Verhalten konzentrieren. Warnsignale sind ungewöhnliche Ressourcenkombinationen, wiederholte Autorisierungsfehler, neue externe Ziele, unerwartete Speicherschreibvorgänge oder Tools, die außerhalb ihrer normalen Reihenfolge eingesetzt werden.

Die achte Kontrolle ist adversariales Testen über vollständige Workflows hinweg. Nur das Basismodell zu testen, ignoriert das Framework, in dem Berechtigungen und Nebenwirkungen liegen.

Der Ansatz von NIST verwendet realistische Tools und Aufgaben, weil Agentensicherheit kontextabhängig ist. Ein Modell könnte einem Angriff in einem einfachen Chat widerstehen, aber scheitern, wenn dieselbe Anweisung in einem vertrauenswürdig wirkenden Geschäftsobjekt erscheint.

Red Teams sollten schädliche Inhalte in jeder Quelle platzieren, die ein Agent verarbeitet. Dazu zählen Websites, E-Mails, Dokumente, Code-Repositories, Issue-Tracker, Tool-Metadaten, Suchergebnisse und gemeinsamer Speicher.

Sie sollten auch Multi-Turn- und Multi-Agenten-Pfade testen. Ein blockierter direkter Befehl könnte erfolgreich sein, nachdem er von einem zwischengeschalteten Agenten umformuliert oder zur späteren Abfrage gespeichert wurde.

Ziel ist nicht, eine einzelne Erfolgsrate für Prompt Injection zu veröffentlichen. Es geht darum zu ermitteln, welche erfolgreichen Injections sensible Daten, privilegierte Tools oder irreversible Vorgänge erreichen.

Das ermöglicht eine bessere Priorisierung. Eine häufige Injection, die nur einen temporären Entwurf verfälscht, verdient Aufmerksamkeit. Eine seltenere Injection, die Produktions-Zugangsdaten erreicht, erfordert zuerst stärkere Kontrollen.

OWASP empfiehlt Least Privilege, die Trennung externer Inhalte, menschliche Freigabe, Ausgabevalidierung und adversariales Testen. Diese Maßnahmen spiegeln ein Defense-in-Depth-Modell wider, statt auf einen einzelnen Detektor zu vertrauen.

Die breitere Angriffstaxonomie von NIST betont ebenfalls, Folgen zu steuern und gleichzeitig Angriffe zu identifizieren. Dieser Ansatz passt zu Agentensystemen, weil vollständige Prävention unsicher bleibt.

Keine dieser Kontrollen macht das Modell vertrauenswürdig. Sie machen das System weniger abhängig von der Vertrauenswürdigkeit des Modells – und das ist das besser vertretbare technische Ziel.

Worauf Google-News-Leser als Nächstes achten sollten

Die entscheidenden Belege werden aus Framework-Standards, messbarer Eindämmung und transparenter Berichterstattung über Vorfälle kommen.

Das erste Signal ist, ob große Frameworks eingeschränkte Ausführung zum Standard machen. Optionale Sandboxing- und Berechtigungskontrollen helfen erfahrenen Teams, aber Voreinstellungen prägen Tausende gewöhnliche Deployments.

Achten Sie darauf, wie Agentenplattformen Tool-Freigaben, Netzwerkzugriff, Dateisystemschreibvorgänge und wiederverwendbare Zugangsdaten handhaben. Ein Framework, das zunächst weitreichende Fähigkeiten bereitstellt und die Härtung später dokumentiert, erhält das zugrunde liegende Risiko.

Die stärkste Standardeinstellung würde kein sensibles Tool automatisch freigeben. Entwickler würden eng begrenzte Fähigkeiten hinzufügen und dabei die Folgen jeder Berechtigung sehen.

Das zweite Signal ist, ob Bewertungen die End-to-End-Auswirkung messen. Raten zurückgewiesener Angriffe sind nützlich, zeigen aber nicht, ob ein erfolgreicher Angriff vertrauliche Daten erreichte oder eine gefährliche Aktion abschloss.

Bessere Bewertungen werden sowohl Modellkompromittierung als auch Systemkompromittierung berichten. Sie werden zwischen einer manipulierten Antwort und einem unbefugten Lesezugriff, einer externen Übertragung, Codeausführung oder einer dauerhaften Speicheränderung unterscheiden.

Sie sollten zudem Ergebnisse über wiederholte Versuche hinweg veröffentlichen. Eine Verteidigung, die einmal erfolgreich ist, aber nach mehreren Varianten scheitert, bietet in einem internetfähigen Dienst nur begrenzten Schutz.

Die Google-Forschungsergebnisse verdeutlichen diesen Bedarf. Prompt-Härtung verbesserte die Widerstandsfähigkeit deutlich, dennoch behielten Multi-Turn-Angriffe eine hohe Fehlerrate. Architektonische Kontrollen bestimmen, was diese verbleibenden Fehler bedeuten.

Das dritte Signal ist die Qualität der Offenlegung. KI-spezifische Vorfälle weisen häufig nicht die vertrauten Artefakte auf, die im herkömmlichen Schwachstellenmanagement verwendet werden. Teams erhalten möglicherweise einen Blogbeitrag eines Anbieters ohne Standardkennung, Angabe betroffener Versionen oder klaren Behebungsweg.

Anbieter von Frameworks sollten Sicherheitswarnungen veröffentlichen, die die vollständige Angriffskette beschreiben. Nutzer müssen die erforderliche Inhaltsquelle, das Modellverhalten, Berechtigungen, Tools, betroffene Versionen und verfügbare Gegenmaßnahmen kennen.

Vage Aussagen, ein Modell habe „zusätzliche Schutzmaßnahmen“ erhalten, reichen nicht aus. Kunden müssen verstehen, ob der Anbieter das Modell, die Framework-Richtlinie, das Berechtigungssystem, die Sandbox oder den Nutzerfreigabeprozess geändert hat.

Derselbe Maßstab sollte für Entscheidungen zu Bug-Bounty-Programmen gelten. Wenn ein Bericht Prompt Injection ohne nennenswerte Auswirkung nachweist, kann eine niedrige Schweregradbewertung angemessen sein. Führt die Injection jedoch zu einer privilegierten Aktion, lenkt es vom eigentlichen Problem ab, sie als erwartetes Modellverhalten abzutun.

Google News wird weiterhin Demonstrationen von Prompt Injections hervorheben, weil sie anschaulich und leicht reproduzierbar sind. Einige werden geringfügige Jailbreaks sein, andere hingegen schwerwiegende Framework-Fehler aufdecken.

Leser sollten drei Fragen voneinander trennen. Hat der Angreifer das Modell beeinflusst? Welche Fähigkeit wurde nach diesem Einfluss verfügbar? Welche unabhängige Kontrolle hätte die daraus resultierende Aktion stoppen müssen?

Diese Abfolge führt zu einer nützlicheren Risikobewertung, als zu fragen, ob Prompt Injection endlich gelöst wurde. Die derzeitige Evidenz liefert keinen Grund, von einer universellen Lösung auszugehen.

Entwickler sollten jeden Pfad zwischen nicht vertrauenswürdigen Inhalten und sensiblen Tools prüfen. Unternehmenskäufer sollten auf aufgabenspezifische Berechtigungen, Herkunftsnachweise, Sandboxing, Freigabekontrollen und auditierbare Ausführungsprotokolle bestehen.

Wissensarbeiter sollten prüfen, worauf ein Agent zugreifen kann, bevor sie E-Mail, Dateien, Kalender und Arbeitsplatzsysteme verbinden. Der Komfort steigt schnell, wenn diese Quellen kombiniert werden, doch damit wächst auch der potenzielle Schadensradius.

Die zentrale Umkehrung bleibt einfach. Prompt Injection ist der Auslöser, während das Framework Reichweite, Autorität und Persistenz bereitstellt. Wer allein den Auslöser behandelt, lässt die gefährliche Maschinerie unverändert.

Wenn eine Schlagzeile in Google News das nächste Agent-Hijacking ankündigt, sollten Sie über die bösartigen Worte hinausblicken. Fragen Sie, welches Tool sie ausgeführt hat, welche Berechtigung sie ermöglicht hat und warum keine separate Kontrolle eingegriffen hat.

Das ist der Test, den Entwickler von Agenten jetzt bestehen müssen. Kann das System sicher bleiben, nachdem sein Modell überzeugt, verwirrt oder schlicht falsch liegt? Wenn die Antwort allein von besserem Prompting abhängt, trägt das Framework den Fehler weiterhin in sich.