Technologie Radar wird geladen
Prompt Injection ist ein zentrales Risiko für LLM-Anwendungen, weil User Input, abgerufene Dokumente, Webseiten, E-Mails, Bilder, Tool-Outputs und Memory Instruktionen enthalten können, die mit der beabsichtigten Policy des Entwicklers konkurrieren. OWASP unterscheidet direkte Prompt Injection, bei der User Input das Modellverhalten ändert, von indirekter Prompt Injection, bei der externe Inhalte wie Websites oder Dateien das Modellverhalten ändern, sobald das Modell sie interpretiert (OWASP LLM01).
Defenses müssen geschichtet sein, weil OWASP ausdrücklich festhält, dass narrensichere Prevention angesichts der Funktionsweise generativer Modelle unklar ist (OWASP LLM01). Starke Systeme trennen Instruktionen von Daten, behandeln Remote Content als nicht vertrauenswürdig, beschränken Tools mit Least Privilege, validieren Outputs und verlangen menschliche Freigabe für risikoreiche Aktionen.
Dies gehört in Adopt für jede produktive LLM-, RAG- oder Agent-System. Prompt-only Defenses reichen nicht; die Security Boundary muss Retrieval, Tool Execution, Identity, Authorization, Logging und nachgelagertes Output Handling umfassen.
Ein einzelner Filter reicht nicht. Angreifer nutzen Obfuscation, Encoding, verstecktes Markup, Multi-Turn-Setup, Tool-Output-Poisoning und RAG Poisoning, um einfache Keyword-Checks zu umgehen (OWASP Cheat Sheet Series).
Agents erhöhen die Blast Radius. Kann das Modell Tools aufrufen, Dateien schreiben, Nachrichten senden, private Systeme abfragen oder Memory persistieren, wird erfolgreiche Injection zu einer echten Aktion statt einer schlechten Antwort.
Guardrails selbst sind angreifbar. OWASP weist darauf hin, dass Guardrail-Modelle ebenfalls anfällig für Prompt Injection sind und daher nur eine Schicht in Defense in Depth sein sollten, nicht die einzige Kontrolle (OWASP Cheat Sheet Series).
Overblocking ist ein Produktrisiko. Strikte Filter können legitime Workflows brechen; Teams brauchen task-spezifisches Risk Scoring, UX-Fallbacks, Eskalationspfade und kontinuierliche Evals für Security und Nützlichkeit.
Adoptieren Sie Defense in Depth für jeden produktiven LLM-Workflow: Instruction/Data Separation, Remote-Content-Quarantine, Least-Privilege Tools, eng begrenzte Credentials, Parameter Validation, Output Validation, Action Allowlists, Rate Limits, Audit Logs und menschliche Freigabe für wirkungsvolle Aktionen. Bei agentischen Systemen jeden Tool Call gegen die ursprüngliche User Intent und aktuelle Permissions validieren, bevor er ausgeführt wird.
Behandeln Sie Prompt Injection als Application-Security-Problem, nicht als Better-Prompt-Problem. Planen Sie adversarial Evals, Red-Team-Tests, Incident Runbooks und Regressionstests für bekannte Injection-Patterns ein, sobald sich Prompts, Retriever, Tools, Modelle oder Memory-Verhalten ändern.