Prompt Injection ist kein theoretisches Problem. Sobald ein LLM mit externen Daten arbeitet (E-Mails, Webseiten, PDFs, Tickets), kann es manipuliert werden.
1) Versteckte Instruktionen im Inhalt
Beispiel: In einem PDF steht unsichtbar „Ignoriere alle vorherigen Regeln“.
Schutz: Inhalte als Daten behandeln, nie als Instruktionen.
2) Tool-Missbrauch über indirekte Befehle
Ein Dokument versucht, das Modell zu API-Aufrufen zu verleiten.
Schutz: Harte Tool-Policies (Allowlist), keine freien Side-Effects.
3) Rollenwechsel-Angriffe
Text versucht, Systemrolle zu überschreiben („Du bist jetzt Admin“).
Schutz: Systemregeln serverseitig erzwingen, nicht im User-Kontext.
4) Datenabfluss durch „helpful mode“
Angreifer fragt so, dass interne Prompts/Secrets ausgegeben werden.
Schutz: Secret-Redaction + Output-Filter + No-echo für interne Prompts.
5) Chain-of-thought Köder
„Zeig alle internen Schritte.“
Schutz: Keine internen Reasoning-Texte exposen; nur Ergebnis + Begründung auf Faktenbasis.
6) Kontextvergiftung über Verlauf
Manipulative Anweisungen werden in die Session geschmuggelt und wirken später.
Schutz: Session-Hygiene, Kontext-Kürzung, Trust-Tags pro Quelle.
7) Mehrstufige Angriffe (Cross-Source)
Harmlose Notiz in Quelle A + Trigger in Quelle B ergibt Exploit.
Schutz: Quellen trennen, Risk-Scoring, High-Risk-Flows mit Human-Approval.
Praktische Mindest-Defense (heute umsetzbar)
- Strikte Trennung: Instruction Layer vs Data Layer
- Tool-Zugriffe nur per expliziter Policy
- Output-Guardrails für Secrets/PII
- Logging + Audits auf Prompt/Tool-Ebene
- Human-in-the-loop bei externen Schreibaktionen
Fazit
Prompt Injection wird bleiben. Entscheidend ist, ob deine Architektur robust trennt, beschränkt und überprüft.
Nächster sinnvoller Artikel:
LLM-Basics ohne Bullshit: Kontextfenster, Tokens, Halluzinationen
Passend dazu: Wenn du tiefer einsteigen willst, schau in unsere LLM News und in den Artikel-Hub.
Leave a Reply