Angriffsflächen: Injection, geliehene Autorität, Ausgabe-Handling

Warum der Agent selbst die Angriffsfläche ist

Klassische Anwendungssicherheit trennt Code von Daten. Ein Sprachmodell kann diese Trennung nicht zuverlässig ziehen, weil Anweisung und Inhalt bei ihm dieselbe Form haben: Text. Was in einem Ticket, einer Webseite oder einem Dateikommentar steht, kommt im selben Kanal an wie die Vorgabe des Betreibers.

Bei einem reinen Chatsystem ist die Folge unangenehm: Das Modell sagt etwas Falsches. Bei einem Agenten ist die Folge eine Handlung. Genau deshalb verschiebt sich die Sicherheitsfrage von „was antwortet das System“ zu „was kann dieses System erreichen, wenn seine Anweisungen von jemand anderem kommen“.

Direkt und indirekt sind zwei verschiedene Probleme

Prompt Injection — Eine Schwachstelle, die auftritt, wenn Eingaben das Verhalten oder die Ausgabe des Modells in unbeabsichtigter Weise verändern.

Direkt

Die Eingabe eines Nutzers verändert das Modellverhalten unerwartet — absichtlich oder unabsichtlich. Der Angreifer ist der Nutzer selbst und hat dessen Rechte.

Indirekt

Das Modell verarbeitet externe Quellen wie Webseiten oder Dateien, deren Inhalt sein Verhalten verändert, sobald er interpretiert wird. Der Angreifer ist niemand, der Zugriff auf das System hat.

Die zweite Zeile ist die für Agenten gefährliche. Bei einer direkten Injection erreicht ein Nutzer, was er ohnehin darf — unschön, aber begrenzt. Bei einer indirekten Injection schreibt jemand, der keinen Zugang hat, in einen Inhalt, den der Agent später liest, und handelt damit mit den Rechten des Agenten. Wer eine Rechnung per E-Mail einreichen kann, hat einen Schreibkanal in euren Agenten.

Vier Größen, die getrennt entschieden werden

Eine Sicherheitsdiskussion über Agenten läuft in Kreisen, solange vier Größen als eine behandelt werden. Getrennt betrachtet ist jede von ihnen eine eigene Entscheidung mit eigener Maßnahme.

Inhalt

Woher kommt der Text, den der Agent liest? Betreibervorgabe, Nutzereingabe oder Fremdinhalt — und ist die Herkunft am Inhalt noch erkennbar?

Autorität

Mit wessen Rechten handelt der Agent? Mit denen des auslösenden Menschen, eines Dienstkontos oder eines Sammelkontos für alle?

Wirkung

Was ist mit dieser Autorität erreichbar, und was davon ist unumkehrbar?

Beobachtung

Bleibt nach einem Lauf genug übrig, um einen Versuch zu erkennen und den Wirkungsradius zu bestimmen?

Der praktische Wert der Trennung zeigt sich am häufigsten Fehler: Ein Team, das ein Injection-Problem hat, arbeitet an der Größe Inhalt — Filter, Erkennung, Prompt-Härtung. Die drei anderen Größen bieten aber Maßnahmen mit garantierter Wirkung, während Maßnahmen am Inhalt grundsätzlich Wahrscheinlichkeitsaussagen bleiben.

Confused Deputy: die geliehene Autorität

Für die Größe Autorität gibt es ein Muster, das älter ist als Sprachmodelle und exakt beschreibt, was hier passiert. Es steht als eigener Eintrag im Schwachstellenkatalog: Unintended Proxy or Intermediary, mit dem Zweitnamen Confused Deputy.

Confused Deputy (CWE-441) — Ein System nimmt eine Anfrage von einer vorgelagerten Komponente an, bewahrt die ursprüngliche Quelle der Anfrage aber nicht ausreichend, bevor es sie an einen Akteur außerhalb seines Kontrollbereichs weiterleitet.

• Der Vermittler hat andere Rechte als der Anfragende — bei einem Agenten praktisch immer der Fall.
• Der Angreifer kann das Ziel nicht direkt erreichen — er hat keinen Zugang zum Zielsystem.
• Der Angreifer formuliert eine Anfrage, die der Vermittler unbeabsichtigt weiterleitet.

Aus dem Wortlaut der Definition folgt die Gegenmaßnahme unmittelbar, und sie ist ungewöhnlich konkret für ein Sicherheitsproblem dieser Art: Wenn ein System als Vermittler zwischen zwei anderen Komponenten auftritt, darf sein Kern die Identität des Auslösers nicht verlieren.

Entscheidend ist, dass die Identität nicht als Argument mitgereicht wird. Ein Feld requested_by im Werkzeugschema wäre wieder Teil des Modellkontexts und damit wählbar — die Kennung gehört in den Authorization-Kopf, den die Ausführungsschicht setzt und das Modell nie sieht.

Herkunft kennzeichnen — strukturell, nicht als Formulierung

Für die Größe Inhalt gibt es eine Maßnahme, die über Filterung hinausgeht und in der Empfehlungsliste ausdrücklich benannt ist: externe Inhalte trennen und kennzeichnen. Der Unterschied zur verbreiteten Umsetzung liegt im Wort „strukturell“.

Untauglich

Fremdinhalt zwischen Trennmarken in denselben Textblock setzen, mit dem Hinweis, alles dazwischen sei nur Daten. Die Marke ist Text und damit fälschbar.

Tauglich

Fremdinhalt in einem getrennten Kanal übergeben — als Werkzeugergebnis mit Herkunftsangabe, nicht als Teil der Anweisung. Und diese Angabe bleibt am Inhalt, auch wenn er weiterverarbeitet wird.

Ergänzend

Die Aktionen, die nach dem Lesen von Fremdinhalt erlaubt sind, enger fassen als die, die ohne Fremdinhalt erlaubt sind.

Die dritte Zeile ist die wirksamste und die am seltensten umgesetzte. Sie verlagert die Kontrolle von der Frage „ist dieser Text ein Angriff“ zu der Frage „was darf ein Lauf noch tun, der fremden Text gelesen hat“. Die erste Frage ist nicht entscheidbar, die zweite ist eine Konfiguration.

Deterministische Ränder statt probabilistischer Mitte

Die empfohlenen Gegenmaßnahmen gegen Injection lassen sich in zwei Klassen sortieren, und diese Sortierung ist die wichtigste Übung dieses Moduls. Beide Klassen sind sinnvoll — aber nur eine erzeugt Zusicherungen.

Verschiebt Wahrscheinlichkeit

Modellverhalten einschränken, Ein- und Ausgabefilter, adversariales Testen. Senkt die Trefferquote von Angriffen, ohne eine Aussage über den Einzelfall zu erlauben.

Erzwingt

Erwartete Ausgabeformate definieren und validieren, Rechtekontrolle und Least Privilege, menschliche Freigabe für Aktionen mit hohem Risiko, Trennung und Kennzeichnung externer Inhalte.

Die ehrlichste Aussage der Quelle steht dabei nicht bei den Maßnahmen, sondern in der Einordnung: Angesichts des stochastischen Kerns dieser Modelle ist unklar, ob es narrensichere Verfahren zur Verhinderung von Prompt Injection gibt. Wer diese Aussage ernst nimmt, baut keine Abwehr, die auf Erkennung beruht — er baut Ränder, die auch dann halten, wenn die Erkennung versagt.

Least Privilege gehört in die Ausführungsschicht

Zwei der Empfehlungen zum Umgang mit übermäßiger Handlungsmacht sind für die Architektur bindend, weil sie festlegen, wo eine Entscheidung fällt.

• Erweiterungen im Sicherheitskontext des jeweiligen Nutzers ausführen — nicht in einem Sammelkontext.
• Die Autorisierung in den nachgelagerten Systemen umsetzen, statt sie das Modell entscheiden zu lassen.
• Die Rechte einer Erweiterung auf das Minimum beschränken, das die Aufgabe verlangt.
• Offene Erweiterungen durch feingranulare ersetzen — statt eines allgemeinen Datenbankwerkzeugs eines je Abfrageart.
• Für Aktionen mit hoher Wirkung eine menschliche Freigabe verlangen, bevor sie ausgeführt werden.

Der vierte Punkt ist der, der im Betrieb den größten Unterschied macht und am meisten Arbeit kostet. Ein Werkzeug run_sql, das beliebige Anweisungen annimmt, hat die Rechte seiner Verbindung — und keine Beschreibung und kein Prompt ändert daran etwas. Fünf Werkzeuge wie get_invoice, list_open_tickets oder get_contract_term haben genau die Rechte dieser fünf Abfragen, und diese Rechte stehen in der Datenbank statt im Text.

Der Preis ist ehrlich zu benennen: Jede neue Fachfrage braucht dann ein neues Werkzeug und damit einen Entwicklungsschritt, während ein allgemeines Abfragewerkzeug sofort alles kann. Genau diese Bequemlichkeit ist der Grund, warum run_sql in so vielen Agenten steht — und warum die Rechteprüfung dort regelmäßig an einer Zeichenkettenanalyse hängt, die sich umgehen lässt.

Laufzeit-Guardrails auf Aktionen

Es bleibt ein Fall übrig, den Least Privilege nicht abdeckt: ein Lauf, der innerhalb der gewährten Rechte Schaden anrichtet. Ein Agent mit legitimem Leserecht auf Kundendaten kann diese Daten massenhaft abrufen, ohne eine einzige Regel zu brechen.

• Erlaubte Operationen als Positivliste — nicht welche Werkzeuge existieren, sondern welche Aufrufe in diesem Lauf zulässig sind.
• Mengen- und Ratenprüfung — ein ungewöhnlich großes Abrufvolumen wird geblockt, nicht nur protokolliert.
• Ausgabevalidierung — die Wirkung wird gegen den erwarteten Zustand geprüft, bevor sie als erfolgreich gilt.
• Auffälligkeitsprüfung auf Zielen — ein Zugriff auf Datensätze, die mit dem Auftrag nichts zu tun haben, ist ein Signal.

Die Ausgabe des Agenten ist fremde Eingabe

Die vierte große Angriffsfläche liegt hinter dem Agenten. Sie hat einen eigenen Namen: Improper Output Handling — unzureichende Validierung, Bereinigung und Behandlung der vom Modell erzeugten Ausgaben, bevor sie an nachgelagerte Komponenten und Systeme weitergegeben werden.

Die Abgrenzung ist wichtig, weil beide Fehler ähnlich klingen: Hier geht es nicht darum, dass man einer Modellausgabe inhaltlich zu sehr vertraut, sondern darum, was ein nachgelagertes System mit ihr macht. Die genannten Fälle sind unspektakulär und real: vom Modell erzeugtes SQL, das Tabellen leert; ein JavaScript-Fragment in einer erzeugten Antwort, das im Browser ausgeführt wird; eine erzeugte E-Mail-Vorlage mit eingebettetem Skript.

Woran man einen Versuch überhaupt erkennt

Ein Injection-Versuch sieht im Protokoll aus wie normale Arbeit — deshalb ist die Größe Beobachtung keine Nachbereitung, sondern Teil der Abwehr. Ohne sie kann man nach einem Vorfall den Wirkungsradius nicht bestimmen und muss vom schlimmsten Fall ausgehen.

• Die vollständige Trajektorie: welche Werkzeuge mit welchen Argumenten, in welcher Reihenfolge, mit welchem Ergebnis.
• Die Herkunft jedes gelesenen Inhalts, damit ein Lauf einem Eingangsdokument zuordenbar bleibt.
• Jeder Zugriff auf Daten, die zum Auftrag nicht passen — das ist das aussagekräftigste einzelne Signal.
• Jede ausgehende Verbindung mit Ziel und Umfang.
• Ungewöhnliche Ausgabemuster, etwa auffällig lange oder kodierte Zeichenketten in einer Modellantwort.

Der dritte Punkt verdient Hervorhebung, weil er die Erkennung von der Textanalyse löst. Man muss den Angriff nicht im Ticket lesen können — es genügt zu sehen, dass ein Lauf zu Ticket 8841 Datensätze von sechzig anderen Kunden angefasst hat.

Adversariales Testen, mit ehrlicher Erwartung

Zu den empfohlenen Maßnahmen gehört ausdrücklich, adversariale Tests und Angriffssimulationen durchzuführen. Der Nutzen ist real, und die Erwartung muss richtig gesetzt sein: Ein solcher Test findet Lücken, er belegt keine Abwesenheit von Lücken.

Praktisch tragfähig ist ein Test, der nicht Formulierungen durchprobiert, sondern Ziele prüft. Statt „erkennt der Filter diese Injection“ lautet die Frage: Kann ein Angreifer, der nur ein Ticket einreichen kann, erreichen, dass Kundendaten das Haus verlassen? Gelingt es, ist die Ursache eine Architekturlücke; scheitert es, ist es an einer Grenze gescheitert, die man benennen kann.

Jeder gelungene Versuch gehört danach als dauerhafter Testfall in die Prüfstrecke — nicht mit seinem Wortlaut, sondern mit seinem Ziel. Wortlaute veralten mit jedem Modellwechsel; Ziele bleiben gültig, solange die Architektur besteht.

Was der Check prüft

• Inhalte nach Herkunft einordnen und benennen, welche Vertrauensstufe daraus folgt.
• Eine indirekte Injection an der Größe angreifen, die eine Zusicherung erlaubt — statt an der, die nur Wahrscheinlichkeit verschiebt.
• Fremdinhalt strukturell kennzeichnen, statt ihn mit Trennmarken im Text zu markieren.
• Modellausgaben vor der Weitergabe an nachgelagerte Systeme so behandeln, dass Struktur und Wert getrennt bleiben.
• Ein Muster geliehener Autorität erkennen und die Identität des Auslösers bis ins Zielsystem durchreichen.
• Eine Berechtigungskonfiguration lesen und die Stelle finden, die Least Privilege aufhebt.
• Für Schaden innerhalb erlaubter Rechte die passende Laufzeitgrenze wählen.
• Einen adversarialen Test auf ein Ziel richten statt auf eine Formulierung.
• Mehrere Schichten so anordnen, dass keine von ihnen als einzige tragen muss.

Der gemeinsame Nenner: Sicherheit agentischer Systeme entsteht nicht daran, Angriffe zu erkennen, sondern daran, die Wirkung eines erfolgreichen Angriffs so klein zu machen, dass sie tragbar ist.