Incident Response

Sicherheitsziel

Incident Response für Prompt Injection ist der koordinierte, evidenzbasierte Prozess, der greift, wenn verdächtige oder bestätigte Modellbeeinflussung einen Ablauf, eine Tool-Aktion, einen Datenfluss, Zugangsdaten, eine Ressource, einen Agenten oder Sub-Agenten oder ein nachgelagertes System betroffen haben könnte. Ziel ist, festzustellen, was tatsächlich geschehen ist, laufende Wirkungen mit der engsten zuverlässigen Kontrolle zu stoppen, die versagende Kontrollgrenze zu reparieren, einen bekannt guten Betrieb wiederherzustellen und Erkenntnisse in die Prävention zurückzuführen.

Bedrohungsmodell

Der Prozess geht davon aus, dass manche eingeschleusten Inhalte in den Modellkontext gelangen, dass Modellverhalten variabel ist und dass probabilistische Erkennung Ereignisse übersieht und harmlose markiert. Außerdem wird angenommen, dass Telemetrie unvollständig sein kann, dass modellbeeinflusster Zustand über einen Lauf hinaus bestehen kann und dass delegierte Agenten und Konnektoren Dritter den Umfang eines Ereignisses erweitern.

Abwehrkontrolle, nicht die Vorfallsdatenbank

Diese Seite beschreibt eine operative Abwehrkontrolle: wie ein Team auf eigene sicherheitsrelevante Ereignisse mit Prompt-Injection-Bezug reagiert. Der Bereich Vorfälle ist etwas anderes. Er katalogisiert öffentlich dokumentierte Fälle, Forschungsdemonstrationen und Advisories mit Quellen und Einordnung. Nichts auf dieser Seite ist ein Fallbericht, und die Szenarien unten sind fiktiv.

Abgrenzung zu anderen Kontrollen

Siehe Erkennung von Prompt Injection, Plan-Drift-Erkennung, Tool-Chain-Analyse, Datenprovenienz, Agentenautorisierung, Human-in-the-Loop, Sandboxing / Eindämmung, Netzwerk- und Egress-Beschränkungen, Informationsflusskontrolle, Least Privilege und Ausgabevalidierung.

Evidenzzustände

Evidenzzustände beschreiben, was die Aufzeichnungen zeigen, vom schwächsten zum stärksten. Jeder Zustand braucht eigene Evidenz; ein höherer Zustand wird nie aus einem niedrigeren abgeleitet.

Sicherheitsereignis und bestätigter Vorfall

Ein Sicherheitsereignis ist jede Beobachtung, die eine Triage verdient, etwa ein Erkennungsalarm zu abgerufenen Inhalten. Ein Vorfall ist in diesem Engineering-Modell ein Ereignis, bei dem Evidenz eine Richtlinien- oder Kontrollverletzung mit tatsächlicher oder glaubhaft möglicher Sicherheitsauswirkung zeigt. Eine bestätigte Auswirkung erfordert Evidenz für Ausführung und Wirkung. Organisationen sollten diese Begriffe an ihre eigene Incident-Richtlinie anpassen; die Definitionen hier sind Engineering-Leitlinien.

Schweregrad und Triage

Der Schweregrad richtet sich nach tatsächlicher oder glaubhaft möglicher Auswirkung, nicht nach der Erkennungskonfidenz. Ein Alarm mit hoher Konfidenz zu Inhalten, die kein Tool erreicht haben, wiegt meist weniger als ein schwaches Signal neben einer ausgeführten privilegierten Aktion.

Vorbereitung

Die Qualität der Reaktion entscheidet sich meist vor dem Ereignis. Wer eine Modellausgabe nicht mit der daraus entstandenen Tool-Anfrage verknüpfen kann, kann einen Vorfall nicht eingrenzen.

Beweissicherung

Evidenz wird gesichert, bevor zerstörerisch bereinigt wird, etwa durch Zurücksetzen von Speicher, Rotation von Logs oder Neuausrollen von Workern. Ist ein Cache geleert, kann die Herkunftskette betroffener Läufe verloren sein.

Rekonstruktion der Zeitleiste

Für jede Aktion wird festgehalten, ob sie vorgeschlagen, versucht, ausgeführt, erfolgreich, fehlgeschlagen oder nicht beobachtet war. Ein Vorschlag im Transkript belegt keine Anfrage; eine übermittelte Anfrage belegt keine abgeschlossene Wirkung.

Eingrenzung

Der Umfang wächst mit der Evidenz. Andere Nutzer oder Mandanten werden nicht als betroffen erklärt, ohne dass Evidenz zeigt, dass sie die relevanten Inhalte oder Zustände verwendet haben.

Eindämmungsoptionen

Bevorzugt wird die engste Kontrolle, die laufende Auswirkungen zuverlässig stoppt; der Umfang wird erweitert, wenn die Evidenz es rechtfertigt. Eine während der Reaktion verschärfte Kontrolle ist eine Vorsichtsmaßnahme, kein Befund bösartiger Absicht.

Zugangsdaten, Token und Geheimnisse

Rotiert oder widerrufen wird, wenn eine Offenlegung bestätigt ist oder ein glaubhaftes Risiko es rechtfertigt. Eine Offenlegung wird nicht behauptet, nur weil ein Geheimnis irgendwo in der Umgebung existierte, und glaubhaft offengelegte Zugangsdaten werden nicht ohne Rotation belassen.

Offenlegung und Veränderung von Daten

Zu unterscheiden sind lesbar, abgerufen, gesendet, empfangen, geändert und gelöscht. "Lesbar" heißt, dass eine Berechtigung bestand; "abgerufen" braucht einen Lesenachweis; "gesendet" einen Anfragenachweis; "empfangen" Evidenz auf der Zielseite; "geändert" und "gelöscht" nachgelagerte Audit-Evidenz, soweit verfügbar. Aussagen über abgeschlossene Übertragungen oder Änderungen stützen sich auf die stärkste verfügbare Evidenz.

Persistenz und Zustand

Modellbeeinflusste Inhalte können in Caches, Speicher, Vektorspeichern, Tool-Zuständen, Dateien, Warteschlangen, gespeicherten Agentenplänen und geteilten Arbeitsbereichen verbleiben. Solcher Zustand gilt als nicht vertrauenswürdige Eingabe, bis er geprüft oder zurückgesetzt ist, und es wird nachverfolgt, welche späteren Läufe ihn verwendet haben.

Multi-Agenten- und delegierte Abläufe

Delegation wird über übergeordnete und untergeordnete Aufgaben-IDs, geerbte Fähigkeiten, zurückgegebene Ergebnisse und agentenübergreifende Provenienz nachverfolgt. Ein Befund bei einem Sub-Agenten belegt nicht automatisch eine Kompromittierung des übergeordneten Agenten, und umgekehrt ist nicht jeder untergeordnete Agent automatisch betroffen. Jedes Glied der Delegationskette braucht eigene Evidenz.

Abstimmung mit Dritten, SaaS und Konnektoren

Audit-Daten der Anbieter werden angefordert, konkrete Berechtigungen bei Bedarf widerrufen und Kennungen auf Anbieterseite wie Anfrage-IDs gesichert. Ein Ereignis auf Anbieterseite wird nicht ohne Evidenz angenommen, und ebenso wenig wird angenommen, dass der Anbieter keine relevanten Aufzeichnungen hat.

Beseitigung und Behebung

Unsichere Inhalte und Zustände werden entfernt, die versagende Vertrauens- oder Kontrollgrenze wird repariert, und Richtlinien, Konfiguration, Zugangsdaten und Integrationen werden nach Bedarf angepasst.

Wiederherstellung

Kommunikation und Eskalation

Kommuniziert wird sachlich und an Evidenzzustände gebunden: betroffener Umfang, Bekanntes und Unbekanntes, ergriffene Maßnahmen und nur verifizierte Auswirkungen auf Kunden oder Nutzer. Begriffe wie "Datenpanne", "Exfiltration" oder "Kompromittierung" werden nur verwendet, wenn Evidenz sie stützt. Entscheidungen über rechtliche und regulatorische Meldungen treffen die zuständigen Verantwortlichen nach der Richtlinie der Organisation.

Nachbereitung

Die Grundursache wird den versagenden oder fehlenden Kontrollebenen zugeordnet: Provenienz, Autorisierung, Berechtigungen, Informationsfluss, Egress, Eindämmung, Erkennung, Ausgabeverarbeitung oder menschliche Freigabe. Begünstigende Umstände wie fehlende Telemetrie, veraltete Berechtigungen oder unklare Zuständigkeiten werden ebenfalls festgehalten.

Erkenntnisse und Kontrollanpassungen

Befunde werden in Erkennungsregeln, Regressionstests, Playbook-Anpassungen, Richtlinienänderungen, Vorgaben zum Datenumgang und Rückmeldungen an Anbieter überführt. Deterministische Kontrollen werden wo möglich repariert, statt nur Prompts oder Klassifikatoren hinzuzufügen.

Evidenz- und Begründungscodes

Die folgenden Codes sind Engineering-Leitlinien für einheitliche Aufzeichnungen, kein Standard.

NO_IMPACT_OBSERVED wird mit EVIDENCE_INCOMPLETE kombiniert, wenn Telemetrielücken bestehen.

Durchgespielte Szenarien

Alle Szenarien verwenden fiktive Systeme und Daten.

A: Erkennungsalarm ohne verändertes Verhalten

In einer abgerufenen Seite erscheint anweisungsähnlicher Text, und die Erkennung schlägt an. Plan und Aktionen bleiben unverändert. Einordnung als verdächtiges Ereignis, Provenienz der Quelle sichern und prüfen, ob die Quelle für den Abruf zulässig bleiben soll. Ergebnis: SUSPICIOUS_CONTENT_OBSERVED, keine bestätigte Auswirkung.

B: Plan-Drift vor der Übermittlung blockiert

Der Plan weicht ab und schlägt eine privilegierte, toolübergreifende Aktion vor. Die Autorisierung lehnt sie vor der Übermittlung ab. Plan, Vorschlag und Entscheidung werden gesichert, Quelle und Entstehung des Vorschlags untersucht. Ergebnis: MODEL_INFLUENCE_OBSERVED und ACTION_PROPOSED; keine nachgelagerte Aktion.

C: Ausgeführte Anfrage mit bestätigter externer Änderung

Eine zulässige Tool-Anfrage wird ausgeführt, und das nachgelagerte Audit-Log bestätigt eine unbeabsichtigte externe Änderung. Ablauf und Tool-Berechtigung werden eingedämmt, Anfrage-, Antwort- und Audit-Evidenz gesichert, betroffene Läufe eingegrenzt, die Grenze behoben und gestuft wiederhergestellt. Ergebnis: ACTION_EXECUTED und DOWNSTREAM_EFFECT_CONFIRMED; bestätigte Auswirkung.

D: Begrenztes Token in einer ausgehenden Anfrage

Ein begrenztes Token liegt in einem Worker, und Logs zeigen, dass es in einer ausgehenden Anfrage an ein nicht freigegebenes Ziel enthalten war. Das gilt als bestätigte Offenlegung und Übertragung dieses Tokens: widerrufen und rotieren, den Egress-Pfad entfernen und eine Nutzung mit dem Anbieter eingrenzen. Andere Geheimnisse gelten ohne eigene Evidenz nicht als offengelegt. Ergebnis: CREDENTIAL_EXPOSURE_CONFIRMED, DATA_TRANSFER_CONFIRMED, TOKEN_REVOKED.

E: Beeinflusster Zustand in einem geteilten Speicher

Modellbeeinflusste Inhalte blieben in einem geteilten Vektorspeicher und beeinflussten einen späteren Lauf. Der Zustand wird in Quarantäne genommen oder zurückgesetzt, Läufe und Nutzer, die ihn verwendet haben, werden eingegrenzt, die Herkunftskette gesichert und ein bekannt guter Zustand wiederhergestellt. Unbeteiligte Mandanten gelten ohne Evidenz nicht als betroffen. Ergebnis: Persistenz und laufübergreifende Wirkung für die nachverfolgten Läufe bestätigt; STATE_RESET.

Was die Szenarien belegen und was nicht

Tests und Planspiele

Zum Üben der Einstufung von Evidenzzuständen an synthetischen Datensätzen eignet sich das Lab Vorfallsuntersuchung.

Für systematische, autorisierte Tests des eigenen Systems über Planspiele hinaus siehe Adversariales Testen.

Kennzahlen

Diese Werte sind operative Messgrößen, kein Nachweis von Sicherheit.

Häufige Fehler

Checkliste zur Umsetzung

Standards und Quellen

Quellenumfang: NIST SP 800-61 Rev. 3 ist eine allgemeine Leitlinie zur Incident Response im Rahmen des Cybersecurity-Risikomanagements; sie ist weder auf Prompt Injection noch auf KI-Systeme zugeschnitten. Die IR-Kontrollen aus NIST SP 800-53 dienen nur der allgemeinen Orientierung. Die OWASP-Liste für agentische Anwendungen liefert Risikokontext zu Agenten und Tools, LLM01:2026 nur Risikokontext zu Prompt Injection. Keine zitierte Quelle definiert dieses Incident-Response-Modell für Prompt Injection als vollständigen Standard. Evidenzzustände, Triage-Dimensionen, Begründungscodes, Szenarien und Kennzahlen auf dieser Seite sind Engineering-Leitlinien.

Häufige Fragen