Du baust einen LLM-Agenten, der Tools aufrufen kann (E-Mail, DB). Benutzereingaben könnten versteckte Anweisungen enthalten. Wie reduzierst du das Prompt-Injection-Risiko?
Kurzantwort
Prompt Injection lässt sich nicht vollständig mit mehr Prompt-Text lösen; nimm an, dass das Modell unterwandert werden kann, und begrenze, was es TUN darf. Gib Tools least privilege, sichere wirkungsstarke Aktionen mit menschlicher Bestätigung ab und validiere oder sandboxe Tool-Aufrufe vor dem Handeln (OWASP LLM „Excessive Agency“ und „Improper Output Handling“). Im System-Prompt zu flehen ist umgehbar. Höhere Temperature fügt nur Zufall hinzu, und reines Logging hält den Schaden fest, ohne die injizierte Aktion zu verhindern.
Ein LLM vermischt Anweisungen und Daten im selben Textstrom, daher kann jeder angreiferkontrollierte Inhalt — direkt getippt oder aus einer E-Mail, einem Dokument oder einer Webseite gezogen, die der Agent liest — Anweisungen tragen, denen das Modell folgen könnte. Das ist Prompt Injection, und sobald das Modell Tools aufrufen kann (E-Mail senden, eine Datenbank abfragen oder ändern), wird aus einer erfolgreichen Injection eine reale Aktion. Dagegen kommst du nicht zuverlässig per Prompt an.
Warum „sag ihm einfach, es solle ignorieren" scheitert
Das Modell hat keine robuste Grenze zwischen deinem System-Prompt und injiziertem Text; beides sind nur Tokens. Eine Zeile „ignoriere bösartige Anweisungen" kann selbst durch eine geschickt formulierte Injection außer Kraft gesetzt werden. Auf der Textebene zu verteidigen heißt, auf dem Heimterrain des Angreifers zu kämpfen.
Die Architektur, die das Risiko wirklich senkt
- Jede Modellausgabe als nicht vertrauenswürdige Eingabe für den Rest deines Systems behandeln. Validiere, typprüfe und begrenze Tool-Argumente vor der Ausführung.
- Least privilege pro Tool. Beschränke jedes Tool auf das Minimum an Daten und Fähigkeiten, mit kurzlebigen, eng gefassten Anmeldedaten — kein breites Admin-Token.
- Menschliche Bestätigung für sensible oder irreversible Aktionen: externe E-Mails senden, Datensätze löschen, Geld bewegen.
- Sandboxen und begrenzen von Ausführung und Netzwerk-Egress, um Exfiltration und SSRF zu begrenzen.
Das entspricht direkt den OWASP-LLM-Risiken Excessive Agency (zu viel Fähigkeit/Autonomie) und Improper Output Handling (Handeln auf Modellausgabe ohne Validierung).
Warum die anderen Optionen scheitern
- Die Temperature erhöhen macht die Ausgaben nur zufälliger; es hat nichts damit zu tun, ob einer injizierten Anweisung gefolgt wird.
- Loggen und hoffen hält den Vorfall fest, nachdem der Schaden geschehen ist — nützlich für Forensik, nutzlos zur Prävention.
Worauf der Interviewer achtet
Ob du verstehst, dass Prompt Injection eine Design-Einschränkung ist und kein Bug, den man per Formulierung patcht, und ob du den Wirkradius klein architektierst: least privilege, Bestätigungsgates und Ausgabenvalidierung, sodass ein unterwandertes Modell trotzdem nicht viel Schaden anrichten kann.
Wahrscheinliche Anschlussfragen
- Was ist indirekte Prompt Injection und warum ist sie für tool-nutzende Agenten besonders gefährlich?
- Welche Tool-Aufrufe würdest du hinter eine menschliche Bestätigung legen, und wie entscheidest du das?
- Wie reduzierst du die „Excessive Agency“ eines Agenten mit E-Mail- und Datenbankzugriff?