Adversariales Testen

Sicherheitsziel

Adversariales Testen für Prompt Injection ist eine autorisierte Absicherungstätigkeit, bei der ein Team das eigene AI-System, seine Kontrollen, Telemetrie und Wiederherstellungspfade unter repräsentativen adversarialen Bedingungen prüft. Ziel ist zu erfahren, wo Vertrauensgrenzen halten, wo sie versagen und ob Fehler beobachtet und behoben werden könnten, bevor diese Bedingungen außerhalb des Tests auftreten.

Bedrohungsmodell

Tests gehen vom selben Bedrohungsmodell aus wie die geprüften Kontrollen: Nicht vertrauenswürdige Sprache kann über direkte Eingaben, externe Inhalte, Retrieval, Tool-Ausgaben, delegierte Agents und persistenten Zustand in den Modellkontext gelangen; Modellverhalten ist variabel; probabilistische Detektoren übersehen manche Ereignisse und markieren manche harmlose; deterministische Kontrollen außerhalb des Modells sollen begrenzen, was beeinflusstes Verhalten bewirken kann.

Tests bringen eigene Risiken mit. Ein Test kann reale Nebenwirkungen auslösen, reale Daten in Testprotokolle tragen oder zu einem unverwalteten Payload-Archiv anwachsen. Das folgende Programmdesign behandelt diese Punkte als zu kontrollierende Risiken, nicht als hinnehmbare Kosten.

Adversariales Testen, Labs und Incident Response

Die Testfallbibliothek bietet geprüfte, sichere Testfälle für jede Testdomäne, gezielt erweitert, wo eine eigene Grenze einen eigenen Fall braucht.

Die Labs veranschaulichen einzelne Ideen und sind keine Testsuite für ein Produkt. Die Methodik Prompt-Injection-Sicherheit testen bietet die praktische Grundlage für Evidenzzustände, lokale Bestehenskriterien und Berichte über reale Systeme. Incident Response behandelt reale Ereignisse; ihre Planspiele sind ein Baustein des Testens, und Erkenntnisse aus Vorfällen fließen hier in Regressionstests ein.

Was Tests belegen können und was nicht

Umfang und Autorisierung

Tests sind autorisiert, abgegrenzt und gesteuert. Ein schriftlicher Umfang nennt Verantwortliche, Systeme, Umgebungen, Identitäten, Tools, Ziele, Datenklassen, Zeitfenster, Abbruchbedingungen und Eskalationskontakte. Tests verleihen keine Befugnis über diesen Umfang hinaus: Die Rolle einer testenden Person autorisiert keine ausgeschlossenen Aktionen, und ein Modell oder Agent kann den Umfang niemals erweitern.

Wahl der Testumgebung

Viele Organisationen sollten in Produktion nie adversarial testen. Wenn doch, bleiben synthetische Identitäten, synthetische Ziele und umkehrbare Aktionen Pflicht.

Inventar der Testbestandteile

Abdeckungsmodell für Vertrauensgrenzen

Abdeckung orientiert sich an Vertrauensgrenzen statt an raffinierten Eingaben. Jede Grenze, an der nicht vertrauenswürdige Inhalte in den Kontext gelangen oder ein Modellvorschlag zur Wirkung wird, braucht Tests in beide Richtungen: erwartetes Zulassen und erwartetes Verweigern.

Aufbau eines Testfalls

Ein Testfall ist ein versioniertes Artefakt. Der folgende Datensatz ist eine technische Empfehlung, kein Standardschema. Er verlangt keine Erfassung von Chain-of-Thought des Modells.

Erwartetes Ergebnis und Orakel-Design

Ein Orakel entscheidet, ob ein Lauf bestanden ist. Orakel für deterministische Kontrollen lesen Durchsetzungsdatensätze und nachgelagerten Zustand: die Autorisierungsentscheidung, das Broker-Protokoll, die synthetische Senke. Orakel für Modellverhalten klassifizieren Ausgaben über wiederholte Läufe. Ein Transkript allein ist ein schwaches Orakel für eine Kontrolle, weil ein Modell eine Aktion behaupten kann, die nie stattfand, oder eine tatsächliche verschweigen kann.

Aussagen zu Modellverhalten und zu Sicherheitskontrollen

Beides nicht zu einem Wert zusammenführen. Eine hohe Abweichungsrate des Modells bei lückenloser Durchsetzung ist eine andere Risikolage als eine niedrige Abweichungsrate bei fehlender Autorisierungsprüfung.

Tests für direkte Injection

Direkte Tests prüfen den Pfad, auf dem die anfragende Person anweisungsähnlichen Text liefert. Relevant ist, ob Anweisungshierarchie und Policy der Anwendung halten und ob jede Abweichung auf die Befugnisse des anfragenden Principals begrenzt bleibt. Zur Angriffsmechanik siehe Direkte Prompt Injection.

Tests für indirekte Inhalte

Indirekte Tests platzieren synthetischen anweisungsähnlichen Text in Web-, E-Mail-, Dokument- oder Suchinhalten, die das System im Auftrag eines anderen Principals verarbeitet. Geprüft wird, dass Provenienz die Extraktion übersteht und nachgelagerte Entscheidungen weiterhin die Befugnisse des initiierenden Principals nutzen. Siehe Indirekte Prompt Injection.

RAG- und Retrieval-Tests

Retrieval-Tests prüfen, dass Relevanz nicht zu Vertrauen wird: dass Mandanten- und Zugriffsfilter vor dem Retrieval greifen, dass Quellmetadaten die Policy erreichen und dass ein synthetisches Dokument aus einer weniger vertrauenswürdigen Quelle nicht verändern kann, was die Anwendung autorisiert.

Tests für Tool-Ausgaben

Tests für Tool-Ausgaben liefern synthetische Ergebnisse mit anweisungsähnlichem Text und prüfen, dass das Ergebnis als Daten behandelt, die Provenienz aufgezeichnet und jeder Folgevorschlag eigenständig autorisiert wird.

Agent- und Aktionstests

Aktionstests prüfen den Schritt, in dem ein Vorschlag zur Wirkung wird. Jeder sollte vorgeschlagen, autorisiert, übermittelt, ausgeführt, erfolgreich, fehlgeschlagen und nicht beobachtet als getrennte Zustände erfassen. Ein Vorschlag ist keine Ausführung, und eine nicht beobachtete Stufe ist kein Beleg, dass nichts geschah.

Multi-Agent- und Delegationstests

Delegationstests prüfen, dass eine Unteraufgabe nur die Fähigkeiten erhält, die der übergeordnete Agent delegieren durfte, dass zurückgegebene Ergebnisse Provenienz tragen und dass übergeordnete und untergeordnete Kennungen korrelieren. Ein Befund beim Sub-Agent begründet nicht automatisch einen Befund beim übergeordneten Agent und umgekehrt.

Autorisierungs- und Least-Privilege-Tests

Autorisierungstests reichen Vorschläge ein, die der Principal ausführen darf und nicht darf, und prüfen die Autorisierungsentscheidung exakt. Least-Privilege-Tests bestätigen, dass Fähigkeiten außerhalb der Aufgabe für die Testidentität gar nicht existieren, statt sich auf eine Ablehnung zu verlassen.

Tests für Informationsfluss und Mandantengrenzen

Flusstests kennzeichnen synthetische Daten nach Quelle und Klassifikation und prüfen, dass die Informationsflusskontrolle unzulässige Bewegungen zu Zielen, Mandanten oder Modellen blockiert, auch über Zusammenfassungen oder abgeleitete Artefakte.

Egress-Tests

Egress-Tests nutzen synthetische Ziele innerhalb und außerhalb der Allowlist und prüfen, dass Egress-Beschränkungen vor dem Verbindungsaufbau verweigern, nach Auflösung und Weiterleitungen erneut prüfen und nicht über einen direkten Netzwerkpfad eines Workers umgangen werden können.

Tests für Ausgabevalidierung und Senkenbehandlung

Validierungstests reichen strukturell ungültige Werte ein und bestätigen, dass die Ausgabevalidierung sie vor der Senke abweist. Bestandene Validierung zeigt Struktur und Format, nicht Vertrauen oder semantische Sicherheit; senkenspezifische Kodierung wird gesondert getestet.

Sandboxing- und Eindämmungstests

Eindämmungstests sind defensive Regressionsklassen: Host-Pfade sind unzugänglich, verweigertes Netzwerk ist nicht verfügbar, Kontingente beenden ausufernde Arbeit, schreibgeschützte Eingaben bleiben unverändert, breite Zugangsdaten fehlen, Export verlangt Freigabe, und nicht verfügbares Sandboxing schlägt geschlossen fehl. Sie vermitteln keine Ausbruchstechniken.

Telemetrietests für Erkennung, Plan-Drift und Tool-Chains

Telemetrietests prüfen, dass Signale aus Erkennung, Plan-Drift und Tool-Chain-Analyse ausgegeben, korreliert und weitergeleitet werden. Trefferquote und Fehlalarmrate von Detektoren werden über wiederholte Läufe gemessen. Eine verpasste Erkennung bei erfolgreicher Durchsetzung ist eine Detektorlücke, kein Sicherheitsversagen der Durchsetzungsschicht.

Tests für Incident Response und Beweissicherung

Diese Tests prüfen, ob sich ein synthetischer Lauf aus Provenienz- und Entscheidungsdatensätzen vollständig rekonstruieren lässt, ob Evidenz vor der Bereinigung gesichert wird und ob Eindämmungsmaßnahmen wie das Widerrufen eines Test-Tokens wie dokumentiert funktionieren.

Tests für Persistenz, Speicher und laufübergreifenden Zustand

Persistenztests schreiben synthetischen, modellbeeinflussten Zustand in Speicher, Caches oder Vektorspeicher und prüfen, dass ein späterer Lauf ihn als nicht vertrauenswürdig behandelt, dass die Herkunftsspur die konsumierenden Läufe benennt und dass ein Zurücksetzen einen bekannten guten Zustand herstellt, ohne unbeteiligte Mandanten zu berühren.

Wiederholung und Nichtdeterminismus

Ein einzelner Lauf reicht für probabilistisches Verhalten nicht. Fälle zum Modellverhalten so oft wiederholen, dass sich eine Rate samt Laufanzahl angeben lässt, und Versionen sowie Seeds erfassen, sofern unterstützt. Deterministische Kontrollen sollten bei gleicher Eingabe und Konfiguration gleich entscheiden; Schwankungen dort sind selbst ein Befund.

Abdeckungs- und Rückverfolgbarkeitsmatrix

Eine praktische Matrix verbindet Eintrittsvektor, Fähigkeit, Grenzkontrolle, erwartete Entscheidung und beobachteten Zustand. Das ist eine technische Empfehlung, kein Standard.

Jede Zelle braucht Fälle mit erwartetem Zulassen und mit erwartetem Verweigern. Ein System, das alles blockiert, ist kein gelungenes Sicherheitsdesign.

Sichere synthetische Fixtures und harmlose Marker

Fiktive Dokumente, falsche Identitäten, synthetische Ziele und harmlose Markierungszeichenketten verwenden, deren Auftauchen in einer Ausgabe oder Senke zeigt, dass Beeinflussung diesen Punkt erreicht hat. Niemals reale Geheimnisse, reale Kundendaten, reale externe Ziele, reale Geldbewegungen, zerstörerische Änderungen oder unkontrollierte autonome Ausführung voraussetzen.

Aus Vorfällen oder Forschung abgeleitete Regressions-Fixtures werden auf das zum Prüfen der Grenze Nötige reduziert, damit die Suite nicht zum Payload-Archiv wird.

Befunde, Evidenzzustände und Schweregrad

Befunde halten Evidenzzustände getrennt: Modellbeeinflussung beobachtet, Kontrollentscheidung aufgezeichnet, Aktion übermittelt, Aktion ausgeführt, Wirkung auf synthetischer Senke bestätigt, Telemetrie fehlend. Ein Detektoralarm ist Evidenz, kein Befund einer Kompromittierung.

Der Schweregrad folgt der erreichbaren Auswirkung, nicht der Raffinesse eines Prompts: welche Privilegien, Datenklassen, Ziele, Mandanten und persistenten Zustände ein Versagen angesichts der tatsächlich haltenden Kontrollen erreichen könnte. Eine aufwendige Eingabe, die nur Formulierungen ändert, wiegt weniger als eine einfache, die einen unautorisierten Schreibvorgang erreicht.

Lebenszyklus der Regressionssuite und änderungsgetriebenes Nachtesten

Regressionsfälle stammen aus dokumentierten Vorfällen, Forschungsergebnissen, Red-Team-Befunden und neu entdeckten Versagen an Vertrauensgrenzen. Jeder Fall wird bereinigt, verantwortet, versioniert und ausgemustert, wenn die geprüfte Grenze nicht mehr existiert.

Durchgespielte Szenarien

Alle Szenarien nutzen fiktive Systeme, synthetische Fixtures und harmlose Marker. Es wird kein Angriffstext gezeigt.

Kennzahlen mit Bezugsgrößen

Das sind operative Messgrößen, kein Sicherheitsnachweis. Sie nicht zu einem aggregierten Sicherheitswert zusammenfassen und Eitelkeitszahlen wie die Anzahl ausprobierter Prompts vermeiden.

Häufige Fehler

Checkliste für die Umsetzung

Standards und Quellen

Quellenumfang: NIST AI 100-2e2025 liefert breite Terminologie und Taxonomie zu adversarialem Machine Learning; es ist kein Teststandard für Prompt Injection. Der OWASP GenAI Red Teaming Guide gibt allgemeine Leitlinien für Red Teaming generativer AI-Systeme; er definiert weder die Abdeckungsmatrix noch das Datensatzschema oder die Kennzahlen dieser Seite. OWASP LLM01:2026 und die Agentic Top 10 dienen als Risikokontext. MITRE ATLAS dient der Orientierung über Bedrohungswissen, nicht als Beleg für die Wirksamkeit eines Tests. Keine zitierte Quelle definiert dieses Modell adversarialen Testens als vollständigen Standard. Abdeckungsmatrix, Testfall-Datensatz, Szenarien, Schweregradansatz und Kennzahlen sind technische Empfehlungen dieser Website.

Häufig gestellte Fragen