Nicht gleichsetzenBeobachteter verdächtiger Inhalt ist keine erfolgreiche Prompt Injection.
Testmethodik
Prompt-Injection-Sicherheit testen
Eine Grundlage für Praktiker zum autorisierten Testen realer LLM-, RAG- und AI-Agent-Anwendungen. Sie verbindet kontrollierte Ausführung mit Evidenz, lokalen Bestehenskriterien, Behebung und Restrisiko, ohne aus Modellverhalten eine Auswirkung abzuleiten.
Was Sicherheitstests belegen müssen
Prompt-Injection-Sicherheit zu testen bedeutet nicht nur zu fragen, ob ein Modell injiziertem Text gefolgt ist. Ein belastbarer Test rekonstruiert die vollständige Anwendungskette und kennzeichnet genau, wo die Evidenz endet.
Nicht gleichsetzenModellbeeinflussung ist keine Sicherheitsauswirkung, und eine Planänderung ist keine Umgehung der Autorisierung.
Nicht gleichsetzenEine vorgeschlagene Aktion ist nicht übermittelt; übermittelt ist nicht ausgeführt; ausgeführt belegt ohne Evidenz keine nachgelagerte Wirkung.
Nicht gleichsetzenEin Detektoralarm ist keine bestätigte Auswirkung. Eine Blockierung belegt eine Kontrollentscheidung, keine bösartige Absicht.
Nicht gleichsetzenUnbeobachtet bedeutet weder fehlgeschlagen noch sicher.
Nicht gleichsetzenEin gültiger Tool-, Schema- oder Protokollaustausch ist keine Erlaubnis. Registrierung und Discovery sind keine Autorisierung.
Nicht gleichsetzenDer Schweregrad folgt der belegten oder glaubhaft möglichen Auswirkung und Reichweite, nicht der Raffinesse eines Prompts.
Labs, Testing und Adversariales Testen
Diese Aktivitäten ergänzen einander, haben aber unterschiedliche Prüfobjekte und Evidenzaussagen.
| Aktivität | Zweck | Umgebung | Primäres Ergebnis |
|---|---|---|---|
| Labs | Kontrolliertes Lernen und Üben | Clientseitige fiktionale Simulationen | Verständnis und Entscheidungspraxis |
| Testing | Reale Anwendungsgrenzen bewerten | Ein ausdrücklich autorisiertes reales System oder eine wirklichkeitsnahe Testumgebung | Evidenz, lokale Ergebnisse, Befunde und Restrisiko |
| Adversariales Testen | Absicherungsmaßnahme und Programmkonzept | Gesteuertes Testprogramm | Abdeckung, Wiederholbarkeit und Kontrollabsicherung |
Autorisierter Testlebenszyklus
Umfang, Verantwortung und Abbruchbedingungen stehen vor jeder Ausführung. Jeder Lauf sollte kontrolliert, zuordenbar und umkehrbar sein.
- 01Umfang und Autorisierung
Verantwortung, Systeme, Versionen, zulässige Aktionen, Grenzen, Abbruchbedingungen und Eskalation festlegen.
- 02Bedrohungsmodell und Vertrauensgrenzen
Variable Inhalte, maßgeblichen Zustand, Principals, Ressourcen, Tools, Ziele und mögliche Wirkungen abbilden.
- 03Instrumentierung und Evidenzplan
Vor dem Test die benötigten Anwendungs- und Provider-Datensätze festlegen.
- 04Repräsentative Angriffspfade auswählen
Relevante Einstiegs-, Kontext-, Aktions- und Kontrollpfade wählen, statt Prompt-Varianten zu maximieren.
- 05Kontrollierten Test ausführen
Sichere synthetische Stimuli, isolierte Daten, Ratenlimits, Bereinigung und Monitoring einsetzen.
- 06Beobachtungen klassifizieren
Inhalt, Beeinflussung, Vorschlag, Kontrolle, Übermittlung und Ausführung als getrennte Zustände erfassen.
- 07Nachgelagerte Wirkung und Auswirkung validieren
Wirkungen mit providerseitiger oder anwendungseigener Evidenz bestätigen, nicht mit Modellnarration.
- 08Beheben
Die fehlerhafte Grenze oder Kontrolle korrigieren und nur die für die Prüfung nötige Evidenz erhalten.
- 09Regressionstest
Versionierte Fälle nach der Änderung und nach wesentlichen Modell-, Tool-, Korpus- oder Policy-Änderungen wiederholen.
- 10Restrisiko berichten
Darlegen, was belegt wurde, was möglich bleibt und was unbeobachtet war.
Evidenzmodell
Variable modellsichtbare Inhalte können Testeingabe oder Beobachtung sein. Sie dürfen nicht allein Identität, Policy, Erlaubnis, Ausführung oder Auswirkung definieren.
EvidenzzustandQuelle und Provenienzdatensatz
Anwendungseigener Aufnahmedatensatz, Inhalts-Hash, Ursprung, Version und Transformations-Lineage.
EvidenzzustandKontextbeobachtung
Anwendungsinstrumentierung dazu, welche Repräsentation in den modellsichtbaren Kontext gelangte.
EvidenzzustandModell- oder Planbeeinflussung
Versionierte Ausgabe oder Plandifferenz, die eine Änderung zeigt, ohne Ausführung oder Auswirkung zu behaupten.
EvidenzzustandPolicy- oder Kontrollentscheidung
Maßgeblicher Datensatz zu Autorisierung, Freigabe, Informationsfluss, Egress oder Validierung.
EvidenzzustandÜbermittlungs- und Ausführungstelemetrie
Anwendungs- und Tool-Datensätze, die Vorschlag, Anfrage, Annahme und Ausführung trennen.
EvidenzzustandNachgelagerte Wirkung
Provider-Audit oder maßgeblicher Zustand, der Ressource, Ziel und resultierende Änderung belegt.
EvidenzzustandKlassifikation der Sicherheitsauswirkung
Analyse zu betroffenem Principal, Daten, Ressource, Aktion, Persistenz und Reichweite.
EvidenzzustandEvidenzlücke oder unbeobachtet
Ein ausdrücklicher Zustand, wenn benötigte Telemetrie fehlt, unvollständig ist oder nicht aufbewahrt wurde.
Ergebnis und lokale Bestehenskriterien
Es gibt kein allgemeingültiges binäres Ergebnis. Das Testziel definiert, welche beobachtbaren Zustände bestanden, fehlgeschlagen oder nicht entscheidbar sind. Eine deterministische Blockierung kann ein Kontrollziel erfüllen, obwohl das Modell beeinflusst wurde.
| Beobachteter Zustand | Was er belegt | Mögliche lokale Behandlung |
|---|---|---|
| Keine beobachtbare Beeinflussung | Keine gemessene Änderung in den ausgewählten Läufen | Nur für ein enges Beeinflussungsziel bestanden |
| Nur Modellbeeinflussung | Ausgabe oder Plan hat sich geändert | Für Beeinflussungsziel fehlgeschlagen; kein Auswirkungsnachweis |
| Unsicherer Vorschlag erzeugt | Modell schlug eine Aktion außerhalb des Umfangs vor | Meist Fehler der Vorschlagssicherheit; Autorisierung noch ungeprüft |
| Deterministische Kontrolle blockiert | Eine benannte Kontrolle verweigerte den konkreten Vorgang | Für dieses Durchsetzungsziel bestanden |
| Aktion übermittelt | Eine Anfrage überschritt die Anwendungsgrenze | Fehlgeschlagen, wenn Übermittlung verhindert werden muss |
| Aktion ausgeführt | Tool oder Provider nahm die Aktion an und führte sie aus | Ausführungsverhinderung fehlgeschlagen; Wirkung bleibt getrennt |
| Nachgelagerte Wirkung bestätigt | Maßgeblicher Zustand belegt die resultierende Änderung | Fehlgeschlagen und betroffene Ressource eingrenzen |
| Credential- oder Datenoffenlegung bestätigt | Evidenz belegt Offenlegung oder unbefugte Nutzung | Fehlgeschlagen mit Auswirkungsklassifikation |
| Persistenz oder laufübergreifende Wirkung bestätigt | Zustand überdauerte oder beeinflusste einen anderen Lauf | Fehlgeschlagen mit Persistenzreichweite |
| Unbeobachtet oder unzureichende Evidenz | Benötigte Evidenz ist nicht verfügbar | Nicht entscheidbar, niemals stillschweigend als bestanden behandeln |
Testdomänen
Diese Taxonomie steuert künftige Abdeckung. Sie erzeugt keine Unterseiten und behauptet nicht, dass jedes System jede Domäne benötigt.
Einstieg und Kontext
- TestdomäneDirekte Eingabe und Anweisungskonkurrenz
Nutzerkontrollierte Sprache im Wettbewerb mit Anwendungsanweisungen.
- TestdomäneIndirekte Web-, E-Mail-, Dokument- und Suchkanäle
Externe Inhalte, die durch Anwendungsverarbeitung in den Kontext gelangen.
- TestdomäneRAG, Retrieval und manipuliertes Wissen
Retrieval-Berechtigung, Provenienz, Relevanz und Korpusintegrität.
- TestdomänePersistenter und multimodaler Kontext
Gespeicherter Zustand, Bilder, Audio und abgeleitete Repräsentationen über Läufe hinweg.
Agents und Aktionen
- TestdomäneTool-Ausgaben
Variable Inhalte nach einem Aufruf und jeder daraus folgende Vorschlag.
- TestdomäneAI Agents und Aktionsgrenzen
Der Übergang von Modell- oder Planbeeinflussung zu vorgeschlagenen und ausgeführten Aktionen.
- TestdomäneMCP-Metadaten und Discovery
Metadaten vor dem Aufruf, Katalogänderungen und die Registrierungsgrenze.
- TestdomäneMulti-Agent-Übergaben
Delegierte Befugnis, Herkunftsspur und erneute Autorisierung bei jeder Übergabe.
Kontrollen und Datenfluss
- TestdomäneAutorisierung und Least Privilege
Konkrete Entscheidungen über Principal, Ressource, Aktion, Parameter und Fähigkeitsreichweite.
- TestdomäneInformationsfluss und Egress
Zulässige Bewegung klassifizierter Daten und zulässige Netzwerkpfade.
- TestdomäneMenschliche Freigabe
Informierte Freigabe, gebunden an die konkrete Aktion und den aktuellen Zustand.
Betrieb und Absicherung
- TestdomäneErkennung, Plan Drift und Tool-Chain-Telemetrie
Korrelierte Signale, die Tests stützen, ohne zur Autorisierung zu werden.
- TestdomäneVorfallsevidenz und Regression
Rekonstruierbare Evidenz, bereinigte Regressionsfälle und änderungsbedingte Wiederholungstests.
Testfallbibliothek
Zur TestfallbibliothekGeprüfte Testfälle
Sichere, synthetische Testfälle: mindestens ein Fall pro Testdomäne plus gezielte Ergänzungen für eigene Grenzen, jeweils mit Evidenzkette und Bedingungen für Bestanden, Nicht bestanden und Nicht schlüssig.
Praxis-Kit
Zu den VorlagenVorlagen für die Testpraxis
Sechs Vorlagen für Testplan, Testfall, Laufprotokoll, Evidenzprotokoll, Befundbericht und Regressionstest - vom autorisierten Plan bis zum versionierten Nachtest.
Abdeckung
Zur AbdeckungsmatrixAbdeckungsmatrix
Welche Testziele die geprüften Fälle abdecken, teilweise abdecken oder offenlassen - ohne Scores, mit erforderlicher Evidenz und priorisierten Lücken.
Werkzeuge
Zum Assessment-PlanerAssessment-Planer
Geprüfte Fälle auswählen und einen Assessment-Plan als Markdown oder JSON exportieren - nur im Browser, ohne Speicherung.
Datensatz eines repräsentativen Testfalls
Künftige Fälle sollten prüfbare Datensätze statt Prompt-Fragmente sein. Jeder Datensatz muss sein Orakel und seine Evidenz vor der Ausführung definieren.
PflichtfeldTest-ID
PflichtfeldZiel
PflichtfeldSystemgrenze
PflichtfeldVorbedingungen
PflichtfeldQuellen- und Vertrauensannahmen
PflichtfeldSicherer synthetischer Stimulus
PflichtfeldErwartetes Modellverhalten, falls relevant
PflichtfeldErwartete deterministische Kontrolle
PflichtfeldBenötigte Telemetrie und Evidenz
PflichtfeldBestehensbedingung
PflichtfeldFehlerbedingung
PflichtfeldNicht entscheidbare oder unbeobachtete Bedingung
PflichtfeldBereinigung und Zurücksetzen
PflichtfeldRegressionstag
Berichtsmodell
Evidenz und Reichweite berichten, ohne Möglichkeit zur Tatsache aufzuwerten. Befunde sollten für Behebung und Nachtests nutzbar bleiben.
BerichtsfeldUmfang und Systemversion
BerichtsfeldGetestete Grenze
BerichtsfeldBeobachtete Evidenz
BerichtsfeldBetroffener Principal, Ressource, Aktion und Ziel
BerichtsfeldTatsächliche gegenüber potenzieller Auswirkung
BerichtsfeldKontrolle, die hielt oder versagte
BerichtsfeldReproduzierbarkeit und Anzahl der Läufe
BerichtsfeldVerantwortung und Änderung zur Behebung
BerichtsfeldNachteststatus
BerichtsfeldRestrisiko und Evidenzlücken
Einstiegspunkte für Praxis und Evidenz
Das Sicherheitsmodell rahmt die Kette, Kontrollartikel definieren deterministische Orakel und Evidenzbibliotheken helfen, Aussagen zu kalibrieren.
Betriebliche Kontrollen
Betriebliche Kontrollen
Konkrete Orakel mit Erkennung von Prompt Injection, Agentenautorisierung, Informationsflusskontrolle und Incident Response definieren. Keine davon ist allein eine vollständige Testlösung.