# Prompt injection in production agents > Prompt Injection ist nicht ein Fehler mit einer Lösung. Es sind fünf Angriffskategorien mit jeweils eigener Abwehr — deshalb bekommen Teams, die einmal eine Eingabebereinigung einbauen, zwei Wochen nach dem Start einen Schwachstellenbericht. Dies ist die gekürzte Fassung des vollständigen Playbooks des Studios. Jede Kategorie unten ist ein wirklich anderer Angriff mit einer wirklich anderen Gegenmaßnahme, und sie als ein Problem zu behandeln ist der Fehler, der immer wiederkehrt. ## Direkte Injection Jemand tippt eine Anweisung ins Chatfeld, die auf deinen System-Prompt zielt. Die Abwehr ist gut bekannt: System- von Nutzerinhalt trennen, die Anweisungshierarchie explizit markieren, Ablehnungsmuster pflegen. Das Versagen liegt nicht im Nichtwissen, sondern darin, es einmal umzusetzen und nie wieder zu prüfen. ## Indirekte Injection über Dokumente Die Anweisung steckt in einer Datei, die der Nutzer hochgeladen hat, oder auf einer Seite, die der Agent geholt hat. Der Nutzer hat nie etwas Feindseliges getippt. Alles, was das Modell liest und der Nutzer nicht selbst verfasst hat, muss als nicht vertrauenswürdiger Inhalt gelten, nicht als Anweisung. ## Vergiftung des RAG-Index Die Nutzlast wird in den Retrieval-Index selbst geschrieben und taucht später bei anderen Nutzern und anderen Fragen auf. Diese Variante überlebt ein Deployment — das macht sie schlimmer als die ersten beiden. ## Missbrauch von Tool-Aufrufen Die Injection zielt nicht auf die Antwort, sondern auf die Werkzeuge. Die Autorisierung muss an der Werkzeuggrenze sitzen und pro Nutzer geprüft werden — nicht aus einem Gespräch abgeleitet, das der Angreifer mitgeschrieben hat. ## Abfluss über gerenderte Ausgaben Daten verlassen das System über das, was die Antwort rendert: ein Link, eine Bildquelle, eine Markdown-Referenz auf den Host eines Angreifers. Den Inhalt der Antwort zu prüfen genügt nicht, wenn man sie danach uneingeschränkt rendert. ## In der CI messen Alle fünf Kategorien gehören in ein Eval-Harness, das bei jeder Änderung läuft — aus demselben Grund wie Unit-Tests. Eine Abwehr, die niemand nachprüft, ist eine Abwehr, die still aufhört zu wirken. ## Was bleibt - Fünf Kategorien, fünf Abwehrmaßnahmen. Ein Bereinigungsfilter deckt eine davon ab. - Alles, was das Modell liest, der Nutzer aber nicht geschrieben hat, als nicht vertrauenswürdig behandeln. - Autorisierung an die Werkzeuggrenze legen, pro Nutzer, nicht in den Prompt. - Einschränken, was die Antwort rendern darf, nicht nur, was sie sagt. - Alle fünf als Evals in der CI fahren, sonst verrotten die Abwehrmaßnahmen unbemerkt. ## Schlagwörter LLM, Prompt injection, OWASP, RAG ## Vollständigen Beitrag lesen https://www.dfieldsolutions.com/blog/llm-prompt-injection-playbook-2026 ## Das bauen wir auch https://dfieldsolutions.com/de/leistungen/cybersecurity ## Mehr aus dem Lab - https://dfieldsolutions.com/de/labor/rag-grounding.md — RAG, das keinen falschen Preis nennen kann - https://dfieldsolutions.com/de/labor/dependency-hygiene.md — Deine tausend Dependencies, auditiert an einem Nachmittag - https://dfieldsolutions.com/de/labor/ai-security-self-audit.md — KI-Sicherheits-Self-Audit - https://dfieldsolutions.com/de/labor/prompt-evals.md — Prompts sind Code: evaluiere sie wie Code --- Source: https://dfieldsolutions.com/de/labor/prompt-injection-playbook DField Solutions — Dunakeszi, Hungary — dezso@dfieldsolutions.com Booking: see https://dfieldsolutions.com/en/contact