Fortgeschritten•10–16 Stunden

Prompt-Injection Source-Sink Lab

Baue ein Red-Team-Labor für direkte und indirekte Prompt Injection, in dem Risiko über den tatsächlichen Pfad von angreiferkontrollierten Quellen zu sensiblen Senken und Side Effects gemessen wird, nicht nur über Instruction Bypass.

Prompt InjectionSource-Sink-AnalyseDatenexfiltrationTool-AutorisierungSecurity Evaluation

Szenario

Aufgabe

Ein KI-Assistent liest Webseiten, Dokumente und RAG-Kontext und kann Tools aufrufen. Prüfe, ob angreiferkontrollierter Inhalt die Offenlegung von Daten, den Aufruf eines gefährlichen Tools oder eine Änderung des Business State auslösen kann, selbst wenn das Modell seine Systemanweisung formal nicht verletzt.

Schrittweise Umsetzung

1. Source-Sink-Modell erstellen

Ergebnis: Jeder angreiferkontrollierte Input und jede folgenreiche Senke besitzt eine explizite Vertrauensgrenze.

Aufgaben

→User-, Web-, RAG-, Tool- und Memory-Quellen inventarisieren
→Secrets, Write Tools und externe Egress-Senken markieren
→Source → Interpreter → Sink-Pfade verbinden
→Festlegen, wo deterministische Policy eine Aktion stoppen muss

Prüfungen

✓Keine Quelle ohne Trust Classification
✓Write- oder Egress-Senken sind nicht nur durch einen System Prompt geschützt

2. Adaptiven Attack Corpus aufbauen

Ergebnis: Tests decken Familien realistischer Angriffe statt nur eines Jailbreak-Prompts ab.

Aufgaben

→Direkte Injection hinzufügen
→Indirekte Web- und Dokument-Injection hinzufügen
→RAG Poisoning hinzufügen
→Tool-Result- und Persistent-Memory-Injection hinzufügen
→Obfuskation und mehrstufige Eskalation hinzufügen

Prüfungen

✓Jeder Fall hat Attack Goal und erwartetes sicheres Ergebnis
✓Der Corpus ist versioniert und reproduzierbar

3. Containment statt nur Refusal testen

Ergebnis: Auch manipuliertes Model Reasoning kann keinen gefährlichen Side Effect auslösen.

Aufgaben

→Jeweils eine Kontrolle deaktivieren
→Allowlists, Denylists und Schema-Validierung testen
→Exact-Action Approval testen
→Network- und URL-Egress-Limits testen
→Secret Isolation testen

Prüfungen

✓Kompromittiertes Reasoning erbt keine Business Authority
✓Jede sensible Senke besitzt eine unabhängige Kontrolle

4. Release Gate einführen

Ergebnis: Eine kritische Source-to-Sink-Regression blockiert den Release automatisch.

Aufgaben

→Evaluations nach Severity aufteilen
→Hard Blocker für Datenexfiltration und nicht autorisierte Writes setzen
→Minimierte Reproduktionen bewahren
→Incident Cases in die permanente Regression Suite aufnehmen

Prüfungen

✓Kein Aggregate Score kann einen kritischen Fehler verbergen
✓Jeder Production Incident kann zu einem reproduzierbaren Testfall werden

Akzeptanzkriterien

Eine vollständige Source-Sink-Karte liegt vor
Der Corpus enthält direkte und indirekte Injection
Sensible Senken haben deterministische Kontrollen
Nicht autorisierte Writes oder Egress sind Hard Blocker
Minimierte Regression Cases und ein Residual-Risk-Owner existieren