Access All Areas

Der Newsletter für technische Entscheider, Business-Strategen und KI-Interessierte.

Heute auf der Setlist: Warum es gegen Prompt-Injection keinen zuverlässigen Filter gibt, und welche Architekturentscheidungen möglichen Schaden trotzdem begrenzen.

🎚️ Soundcheck

Sobald ein KI Agent Tools aufrufen darf, ändert sich die Sicherheitslage für angebundene Systeme grundlegend. Ein Chatbot, der nur antworten kann, kann höchstens etwas Falsches als Antwort zurückgeben. Ein Agent, der E-Mails verschickt, Datenbanken abfragt oder sogar verbindliche Bestellungen auslöst, kann eben etwas Falsches tun.

Der wichtigste Angriffsweg dafür heißt Prompt-Injection: Anweisungen, die in Inhalten versteckt sind, die der Agent verarbeitet. Die OWASP Top 10 für Agentic Applications führen diesen Angriff auch 2026 auf Platz 1, und bei der Prävention ist der Stand der Dinge ernüchternd: OWASP selbst hält fest, dass bis heute kein zuverlässiger Schutzmechanismus existiert. Diese Ausgabe erklärt, warum das so ist, und welche Architekturentscheidungen den Schaden trotzdem wirksam begrenzen.

🎤 Main Set: Der Angriff, den kein Filter stoppen kann

Wie eine indirekte Prompt-Injection abläuft

Der Angreifer braucht dabei keinen Zugriff auf das System. Er braucht nur einen Weg, Text in die Verarbeitung des Agenten zu bekommen. Ein Beispiel: Ein Support-Agent liest eingehende Tickets und darf zur Recherche auf Kundendaten zugreifen. Ein Angreifer schreibt nun ein Ticket, das mitten im Text eine Anweisung enthält, etwa die Aufforderung, alle Kundendaten an eine externe Adresse zu senden. Der Agent liest das Ticket, hält die Anweisung für einen legitimen Auftrag und führt sie mit seinen eigenen Berechtigungen aus.

Für RAG-Systeme kommt eine gerne übersehene Variante hinzu: Auch der eigene Dokumentenbestand ist ein Einfallstor. Eine präparierte Anweisung in einem hochgeladenen PDF oder einer indexierten Webseite wird beim Retrieval ganz regulär in den Kontext geholt und wirkt dort genauso wie eine direkte Eingabe.

Warum Filter das nicht lösen

Der Grund liegt in der Funktionsweise der Modelle selbst. Ein Sprachmodell verarbeitet System-Prompt, Nutzereingabe und abgerufene Inhalte als einen einzigen Strom von Token. Es gibt schlicht keine technische Markierung, die einen Teil verbindlich als Befehl und einen anderen als bloße Daten kennzeichnet. Erkennungs-Heuristiken und Eingabefilter können die „Trefferquote“ von solchen Angriffen senken, sie garantieren aber nicht, dass das immer funktioniert, und ein einziger durchgerutschter Angriffsversuch genügt ja schon, um erheblichen Schaden anzurichten.

Dass OWASP zugleich die Kategorie „Excessive Agency“, also zu weitreichende Handlungsvollmachten des Agenten, von Platz 6 auf Platz 3 hochgestuft hat, zeigt die Richtung der Konsequenz recht deutlich: Wenn sich der Angriff nicht zuverlässig verhindern lässt, muss die Architektur begrenzen, was ein erfolgreicher Angriff überhaupt anrichten kann.

🥁 Track 2: Die Lethal Trifecta, und wie man sie aufbricht

Die klarste Entscheidungsregel dafür stammt von Simon Willison und wird inzwischen von OWASP als Prüfschritt vor dem Deployment zitiert. Gefährlich wird ein Agent dann, wenn drei Eigenschaften zusammenkommen:

• Zugriff auf private Daten, etwa Kundendaten, Verträge oder interne Systeme
• Kontakt mit nicht vertrauenswürdigen Inhalten, z. B. E-Mails, Webseiten oder hochgeladenen Dokumenten
• Fähigkeit zur externen Kommunikation, wie E-Mail-Versand, HTTP-Aufrufe oder Schreibzugriffe nach außen

Jede Eigenschaft für sich ist erstmal harmlos. Kommen aber alle drei zusammen, wird der Agent durch eine einzige eingeschleuste Anweisung zum Exfiltrationswerkzeug: Er liest die Anweisung im fremden Inhalt, holt die privaten Daten und sendet sie nach draußen.

Daraus ergeben sich folgende wirksamen Gegenmaßnahmen:

• Die Trifecta auftrennen: Ein Agent, der fremde Inhalte liest, bekommt keinen externen Kommunikationsweg, oder keinen Zugriff auf sensible Daten. Braucht ein Workflow wirklich alle drei Fähigkeiten, wird er auf mehrere Agenten mit kontrollierten Übergaben aufgeteilt.
• Berechtigungen pro Tool statt pro Plattform: Das häufigste Muster ist ein Tool, das an einem Service-Account mit weit mehr Rechten hängt, als die Funktion braucht. Jedes Tool bekommt darum nur die Rechte seiner konkreten Aufgabe, im Zweifel nur Lesezugriff auf einen definierten Ausschnitt. Das ist übrigens derselbe Grundsatz, der in #007 bei den Zugriffsrechten im Retrieval auftauchte, hier nun aber auf Aktionen angewandt.
• Freigaben für irreversible Aktionen: Löschen, Versenden, Überweisen und vergleichbare Schritte laufen über eine menschliche Bestätigung, also Human-in-the-Loop, oder über eine deterministische Regel, nicht aber über das eigene Ermessen des Modells.
• Protokollierung der Tool-Aufrufe: Ohne Aufzeichnung, welcher Agent wann welches Tool mit welchen Argumenten aufgerufen hat, bleibt ein Vorfall unentdeckt oder unaufklärbar. Die Trace-Infrastruktur, welche in Ausgabe #008 beschrieben wurde, leistet genau das ohnehin schon.

🎯 Encore: Der eine Gedanke für Entscheider

Prompt-Injection lässt sich nach heutigem Stand nicht zuverlässig verhindern, und jede Sicherheitsstrategie, die auf einen einfachen Filter vertraut, vertraut damit auf etwas, was der Hersteller der Maßnahme selbst nicht garantiert. Verlässlich begrenzen lässt sich ein potentieller Schaden nur über Berechtigungen, Architektur und Freigaben. Das ist tatsächlich eine gute Nachricht, denn diese Instrumente sind etabliert und liegen vollständig in der eigenen Hand.

Die Prüffrage für Entscheider: Können wir für jeden Agenten benennen, welche der drei Eigenschaften der Lethal Trifecta er besitzt, und mit welchen Rechten jedes seiner Tools tatsächlich läuft?

💿 B-Side

Anti-Pattern: Ein Tool mit dem breiten Service-Account der Plattform verdrahten, weil es halt schneller geht. Hinter einem Modell, das sich früher oder später zu einem Aufruf überreden lässt, wird aus einer einzigen eingeschleusten Anweisung ein Vollzugriff. Die wahrscheinlich schlimmste Variante davon ist die Datenbankrolle mit Schreib- und Löschrechten hinter einem Agenten, der Nutzereingaben verarbeitet.

---

Das war Rag'n'Roll #012. Die nächste Ausgabe geht an den Anfang der Pipeline: warum beim Parsing und Chunking von Dokumenten still Antworten verloren gehen, und was strukturerhaltende Parser und kontextbewusstes Chunking dagegen ausrichten.

Weiterleiten erwünscht🤘