Gefährliche Anweisungen können in Quellen stehen
Bei einer indirekten Prompt Injection enthält beispielsweise eine eingelesene Webseite die Aufforderung, vertrauliche Daten weiterzugeben. Aus Sicht der Anwendung ist die Seite eine Quelle, keine autorisierte Steuerung. Diese Grenze muss technisch berücksichtigt werden. RAG verbessert den Zugriff auf Wissen, beseitigt das Angriffsproblem aber nicht. OWASP führt Prompt Injection ausdrücklich als eigene Risikoklasse.
Folgen begrenzen statt perfekte Erkennung versprechen
Ein Modell sollte nur die Daten erhalten, die der aktuelle Nutzer lesen darf. Werkzeuge brauchen enge Funktionen statt allgemeinen Systemzugriff. Ein Werkzeug zum Abfragen einer Rechnung benötigt keine Möglichkeit, beliebige Dateien zu versenden. Schreibende Aktionen sollten unabhängig vom Modell geprüft werden; bei kritischen Vorgängen sind zusätzliche Freigaben sinnvoll.
Ausgaben bleiben ungeprüfte Eingaben
Generierter Text darf nicht direkt als SQL, HTML oder Shellbefehl ausgeführt werden. Strukturierte Ausgaben müssen gegen erwartete Felder und zulässige Werte validiert werden. Auch ein korrektes JSON-Format beweist keine fachliche Richtigkeit. Sicherheitsprüfungen sollten Angriffe über Dokumente, Suchtreffer und Werkzeugrückgaben abdecken, nicht nur direkte Chatnachrichten.
Beispiel: Eine interne Beschaffungsassistenz
Ein manipuliertes Angebot fordert den Agenten auf, interne Kalkulationen an eine fremde Adresse zu senden. Eine robuste Anwendung hat weder ein beliebiges Versandwerkzeug noch unbeschränkten Zugriff auf die Kalkulation. Der Angriff wird dadurch in seiner Wirkung begrenzt, selbst wenn das Modell die falsche Anweisung sprachlich aufgreift.
Womit Sie sinnvoll beginnen können
- Datenberechtigungen vor Suche und Kontextaufbau durchsetzen.
- Werkzeuge nach minimal notwendiger Befugnis zuschneiden.
- Tests mit präparierten Quellen und unerlaubten Folgeaktionen ergänzen.