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

> Warum ein Agent, der fremde Inhalte liest, fernsteuerbar ist: indirekte Injection, Herkunftskennzeichnung, Confused Deputy und durchgereichte Identität, Least Privilege in der Ausführungsschicht, Laufzeitgrenzen auf Aktionen und die Ausgabe als fremde Eingabe.

Track: [Agentic AI](https://physar.tech/learn/agentic-ai)  
Kanonische Fassung: https://physar.tech/learn/agentic-ai/agent-security  
Stand: 2026-09-04  
Interaktiver Teil: 9 Checks (nur im Browser)

## Angriffsflächen: geliehene Autorität, fremde Anweisungen und die Ausgabe als Eingabe

### 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“.

> **Merksatz:** Ein Agent ist kein System, das angegriffen wird. Er ist ein System, das im Angriffsfall **für den Angreifer arbeitet** — mit deinen Rechten, in deinem Netz, unter deinem Namen.

### 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**.

Mensch meldet sich an; die Sitzung trägt seine Identität → Agent erhält den Auftrag — die Identität bleibt an der Sitzung, nicht im Prompt → Ausführungsschicht ruft das Zielsystem im Namen dieses Menschen auf, etwa per `on-behalf-of`-Token → **Zielsystem entscheidet über die Berechtigung und protokolliert die Person, nicht den Agenten**

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.

### Der Agent, der für alle handelt

Ein Ops-Agent nimmt Anfragen aus einem Chat entgegen und ruft damit interne APIs auf — Deployment, Log-Zugriff, Konfiguration. Er nutzt dafür ein Dienstkonto mit den vereinigten Rechten aller Teams, weil sonst „ständig etwas fehlt“. Jeder Mitarbeitende kann ihn ansprechen.

**Anforderungen**

- Ein Nutzer darf über den Agenten nicht mehr erreichen als direkt
- Aktionen müssen im Zielsystem einer Person zurechenbar sein
- Der Agent soll weiterhin für alle Teams nutzbar bleiben

**Schritte**

- Befund: Alle drei Bedingungen des Musters liegen vor. Der Agent hat mehr Rechte als jeder einzelne Nutzer, die Nutzer erreichen die APIs nicht direkt, und der Agent leitet weiter, was ihm gesagt wird.
- Erste Korrektur: Die Identität des auslösenden Menschen wird bis zum Zielsystem durchgereicht, statt am Agenten zu enden.
- Zweite Korrektur: Die Autorisierung fällt im **Zielsystem** gegen diese Identität — nicht im Agenten und nicht im Prompt.
- Dritte Korrektur: Das Sammel-Dienstkonto wird abgeschafft. Der Agent hat eigene Rechte nur für das, was er ohne Auftrag tut, etwa seine eigene Telemetrie.
- Gegenprobe: Ein Nutzer ohne Deployment-Recht bittet den Agenten um ein Deployment. Der Versuch muss im Zielsystem mit einem Berechtigungsfehler enden — nicht daran scheitern, dass der Agent es ablehnt.

**Merksatz:** Solange die Autorisierung im Agenten fällt, ist sie eine Modellentscheidung. Erst im Zielsystem gegen eine durchgereichte Identität wird sie eine Zusicherung.

### 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.

> **Merksatz:** Ein Filter mit 95 Prozent Erkennungsrate lässt jeden zwanzigsten Versuch durch. Ein Angreifer versucht es mehr als zwanzigmal.

### 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.

**Kurzcheck:** Ein Agent hat eng gefasste, ausschließlich lesende Zugangsdaten und einen sorgfältigen Systemprompt. Security fragt, was ihn davon abhält, im erlaubten Leseumfang massenhaft Daten abzufließen. Was fehlt?

- [x] Erzwungene Prüfungen auf Aktionsebene: Positivliste der Operationen und Mengengrenzen, unabhängig vom Prompt
- [ ] Die Leserechte weiter einschränken, bis kein massenhafter Abruf mehr möglich ist
- [ ] Den Systemprompt um ein Verbot massenhafter Abrufe ergänzen
- [ ] Das Abrufvolumen überwachen und bei Auffälligkeiten alarmieren

> Genau die Schicht, die zwischen erlaubtem und unangemessenem Gebrauch derselben Rechte unterscheidet. Sie wirkt, ohne den Angriff erkennen zu müssen.

### 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.

### Die Zusammenfassung, die eine Tabelle geleert hat

Ein Agent erzeugt aus einer Fachanfrage eine SQL-Abfrage und führt sie über eine Datenbankverbindung aus. Nach einem manipulierten Ticket enthielt die erzeugte Abfrage eine zweite Anweisung, und eine Tabelle war leer.

**Anforderungen**

- Erzeugte Abfragen dürfen keine unbeabsichtigten Anweisungen ausführen
- Der Fachfall bleibt bedienbar
- Der Fehler soll strukturell ausgeschlossen sein, nicht erkannt werden

**Schritte**

- Grundhaltung übernehmen: Die Modellausgabe wird wie die Eingabe eines gewöhnlichen Nutzers behandelt — mit Null-Vertrauen und vollständiger Validierung.
- Freies SQL abschaffen: Statt einer Abfragezeichenkette liefert das Modell **Parameter** für vorbereitete Anweisungen — die Abfrage steht im Code als `SELECT … WHERE kunde = ?`, das Modell liefert nur den Wert für `?`.
- Damit ist die Struktur der Abfrage nicht mehr Teil der Modellausgabe, und eine angehängte zweite Anweisung ist kein gültiger Parameterwert.
- Für die verbleibenden Fälle, in denen Struktur nötig ist, eine Positivliste erlaubter Formen statt einer Erkennung verbotener.
- Kontextgerechte Kodierung überall dort, wo die Ausgabe in HTML, in eine Datei oder in eine Kommandozeile gelangt.
- Gegenprobe: derselbe manipulierte Eingang, jetzt mit erwartetem Ergebnis — ein Parameterwert, der nichts ausführt.

**Merksatz:** Vorbereitete Anweisungen sind hier keine Optimierung, sondern die Grenze: Sie machen die Trennung von Struktur und Wert zu einer Eigenschaft des Aufrufs statt zu einer Eigenschaft des erzeugten Textes.

### 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.

> **Preis der richtigen Wahl:** Zielorientierte Tests brauchen eine Umgebung, in der ein gelungener Angriff auch tatsächlich wirkt — also echte Werkzeuge gegen eine echte Testinstanz. Das ist aufwendiger als ein Prompt-Katalog und die einzige Variante, deren Ergebnis etwas über den Betrieb aussagt.

### 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.

## Quellen

- OWASP GenAI Security Project — LLM01 Prompt Injection — https://genai.owasp.org/llmrisk/llm01-prompt-injection/
- OWASP GenAI Security Project — LLM05:2025 Improper Output Handling — https://genai.owasp.org/llmrisk/llm052025-improper-output-handling/
- OWASP GenAI Security Project — LLM06:2025 Excessive Agency — https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
- MITRE — CWE-441: Unintended Proxy or Intermediary (Confused Deputy) — https://cwe.mitre.org/data/definitions/441.html
- Simon Willison — The lethal trifecta for AI agents — https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/