Prompt Injection bezeichnet Angriffe oder unbeabsichtigte Interaktionen, bei denen Instructions aus User Input oder externem Content ein Sprachmodell vom beabsichtigten Verhalten abbringen. Sie ist direkt im Prompt oder indirekt in Dokumenten, Webseiten, Nachrichten und Toolresultaten.
Sprachmodelle verarbeiten Instruktion und Daten im selben Sprachkanal. Ein Satz in einem Dokument kann mit dem Systemtask konkurrieren, und das Modell schafft keine deterministische Sicherheitsgrenze. Die Folge wird ernst, wenn Secrets, breite Tools oder Aktionsrechte verfügbar sind.
Eine stärkere Warnung im System Prompt löst Prompt Injection nicht. Nehmen Sie Beeinflussbarkeit an und bauen Sie das System so, dass manipulierter Output weder Userrechte überschreitet, unnötige Daten offenlegt noch ohne Policy und Approval handelt.
Angriffspfade
Indirekte Injection macht normalen Content zum Instruktionskanal
Direkte Injection steht in der User Message, etwa Ignore Prior Constraints. Indirekte Injection liegt in Content, den die Anwendung später liest: Webseite, PDF, Ticket, Kalender oder Knowledge Article. Der User sieht sie möglicherweise nie.
Ein Agent verstärkt das Risiko durch Aktionen. Eine Seite kann einen Browseragenten zum Senden von Daten oder zu veränderten Toolargumenten auffordern. Provenance und Hierarchie helfen, aber Safety entsteht durch begrenzte Daten und Autorität ausserhalb des Modells.
| Surface | Beispiel | Primäre Kontrolle |
|---|---|---|
| User Input | Task Override | Capability- und Outputgrenze |
| Dokument | Versteckte Action | Untrusted-Content-Handling |
| Tool Result | Schädlicher API-Text | Schema und Provenance |
| Memory | Persistente hostile Instruction | Write Policy und Isolation |
| Model Output | Command oder Markup | Downstream Validation |
Abwehr
Für ein Modell entwerfen, das falschen Instruktionen folgen kann
Instructional Defenses reduzieren Angriffe, bleiben probabilistisch. Harte Controls sind bekannte Security Engineering: Least Privilege, Authorization, Data Minimization, Isolation, validierte Interfaces, Confirmation, Monitoring und Incident Response.
Kontrollen folgen der Konsequenz. Ein Drafting Tool ohne Secrets und Action hat weniger Impact als ein Agent für Email, Purchase oder Record Change. Erhöhen Sie Review und Sandboxing mit der Autorität und halten Sie deterministischen Stop vor irreversiblem Effekt.
- Prompt nie als Authorization Layer nutzen.
- Secrets aus modelllesbarem Kontext halten.
- Retrieved und Tool-Text als untrusted behandeln.
- Im ausführenden oder rendernden Component validieren.
- Side Effects statt nur Refusal testen.
Woran gute Arbeit erkennbar ist
Konkrete Ergebnisse für Prompt Injection
- Untrusted Content ist über alle Inputpfade explizit markiert.
- Secrets und unnötiger sensibler Kontext bleiben ausserhalb der Prompts.
- Tool Authorization wird bei jedem Call ausserhalb des Modells erzwungen.
- High-impact-Aktionen benötigen Checks und Bestätigung.
- Attack Tests messen Modellreaktion und Downstream Side Effects.
Betriebsmodell
So wird die Arbeit ausgeführt
- 01
Instruktions- und Datenkanäle kartieren
Inventarisieren Sie System Instructions, User Messages, Files, Web Content, Emails, Memory und Tool Results. Markieren Sie Trust, Owner und Berechtigung. Content von Kunden, Dritten oder früherem Model Output bleibt untrusted, auch im Geschäftsdokument.
- 02
Erreichbare Autorität reduzieren
Legen Sie keine wiederverwendbaren Secrets in Prompts. Geben Sie Tools enge Operationen und Minimalrechte, autorisieren Sie bei Execution und scopen Sie auf User und Resource. Trennen Sie Read, Draft und Act, damit Content Processing nicht still handelt.
- 03
Effekte begrenzen und validieren
Nutzen Sie strukturierte Tool Schemas, Allowlists, Input Validation, Output Encoding und Transaction Controls. Zeigen Sie materielle Aktionen vor Bestätigung. Validieren Sie Modell-URLs, Code, Queries und Markup im empfangenden System.
- 04
Reale Angriffspfade testen
Platzieren Sie adversarial Instructions in Prompts, Dokumenten, Metadaten, Webseiten und Tool Outputs. Testen Sie Data Exfiltration, Goal Redirection, Tool Misuse und Persistenz. Erfassen Sie verhinderte Wirkung statt natürliche Refusal-Sprache.
Bewertung
Fragen, die den Entscheid verändern
- Welche Inputs kann ein untrusted Actor direkt oder indirekt beeinflussen?
- Welche Daten und Tools sind für den Task unnötig?
- Wo wird Autorisierung bei einer Modellaktion erzwungen?
- Welcher Output wird ausgeführt, gerendert oder extern gesendet?
- Welche Human Confirmation ist vor einem Side Effect sinnvoll?
Fehlermuster
Wo Teams die Kontrolle verlieren
Ein Retrieved Document lenkt einen Agenten zu einem Angreiferziel.
Prompt Secrecy schafft falsche Sicherheit, weil Kontext leaken kann.
Ein overprivileged Tool macht generierten Text zur unzulässigen Aktion.
Model Output injiziert Code in einen Downstream Interpreter.
Memory bewahrt schädliche Instructions über spätere Sessions.
Messung
Das fertige Ergebnis messen
Gemessen wird der abgeschlossene Prozess inklusive Review-Aufwand und Ausnahmen. Reines Output-Volumen beweist noch keine bessere Arbeitsweise.
- vor materieller Wirkung blockierte Attack Scenarios
- von Policy abgelehnte unzulässige Tool Requests
- sensible Felder im Modellkontext je Task
- High-impact-Aktionen mit gültiger Confirmation
- von Downstream Validation abgelehnter Output
- Regression Coverage je Injection-Kanal
Fragen
Häufige Fragen
Was ist Prompt Injection?
User Input oder externer Content liefert Instructions, die das Sprachmodell vom beabsichtigten Applikationsverhalten abbringen.
Was ist indirekte Prompt Injection?
Eine Instruction in Dokument, Webseite, Email oder Tool Result, welche die Anwendung später dem Modell gibt. Der Angreifer interagiert nicht zwingend direkt.
Verhindert ein System Prompt die Injection?
Er kann Verhalten verbessern, ist aber keine deterministische Sicherheitsgrenze. Least Privilege, externe Authorization, Datenminimierung, validierte Tools und Approval schützen.
Ist Prompt Injection ein Jailbreak?
Die Begriffe überlappen. Jailbreaking zielt meist auf Modellrestriktionen, Prompt Injection auf Applikationsinstruktionen und kann externe Inhalte und Tools ausnutzen.
Quellen
Primärquellen
- LLM01:2025 Prompt Injection OWASP Gen AI Security Project
Über den Autor
Tony Kim
Tony schreibt über angewandte AI, verlässliches Product Engineering und Systeme, die komplexe Response-Arbeit kontrollierbar machen.
Zeke
AI Product Engineering, das aus einem Software-Briefing ein zuverlässiges Produkt im Betrieb macht.
Produktverantwortliche, Gründungsteams und Software-Engineering-Teams. Ausgangspunkt sind der bestehende Ablauf, seine Grenzen und die vorhandenen Nachweise.
Zeke ansehen→