KI & Sicherheit

Incident Response

Was bei Verdacht auf falsche Agentenaktionen, Datenabfluss oder Supply-Chain-Probleme sofort zu tun ist.

Stand: 2026-06-05

Kurzfassung

  • Bei Verdacht stoppen, sichern, melden, nicht weiterprobieren.
  • Erste Anlaufstelle ist der technische Lead oder Maintainer.
  • Der Entwickler darf sofort Tool/Agent stoppen und Zustand sichern.
  • Kein Aufräumen, kein Force Push, kein Weiterexperimentieren ohne Lead.
  • Rollback darf nicht erst im Vorfall erfunden werden.
  • Wenn ein Secret im KI-Kontext war, gilt es als kompromittiert, bis fachlich anders bewertet.
  • Jeder relevante Verdacht bekommt eine kurze Incident-Notiz.
  • Vorfälle werden einfach in niedrig, mittel und hoch eingestuft.

Thema

Umgang mit Verdacht und Vorfällen durch KI-Tools, Agenten, Drittanbieter-Updates, Rule-Packs, Plugins, MCP-Integrationen, Git, Deployment oder externe Systeme.

Ausgangslage

Realistische Vorfälle im Entwickleralltag:

  • kompromittiertes npm-/pnpm-/Composer-/TYPO3-Update,
  • KI-Agent führt falschen Command aus,
  • KI-Agent ändert falsche Dateien oder falsches Projekt,
  • nicht freigegebenes KI-Tool sieht Projektcode,
  • Secrets, Dumps oder Logs geraten in KI-Kontext,
  • falscher Push oder falscher Merge Request,
  • Deployment mit unerwarteter Wirkung,
  • Rule-Pack, Plugin oder MCP-Integration macht etwas Unerwartetes,
  • Trello oder Jira wird falsch beschrieben.

Für solche Fälle gibt es aktuell keine für alle bekannte Routine und keine einfache TODO-Anleitung.

Die wichtigste praktische Erkenntnis:

Im Vorfall ist Improvisation selbst ein Risiko.

Risiko in einem Satz

Wenn ein Verdacht nicht sofort gestoppt und sauber dokumentiert wird, wird der Schaden größer, Spuren werden schlechter und Rollback-Entscheidungen werden unsicherer.

Grundsatz

Bei Verdacht wird nicht weiterprobiert.

Bei Verdacht stoppen, sichern, melden, nicht weiterprobieren.

Das Ziel ist schnelle Schadensbegrenzung, nicht sofort perfekte Analyse.

Sofortablauf

1. Stoppen

  • Agent oder Tool anhalten,
  • keine weiteren Commands ausführen,
  • keinen weiteren Push ausführen,
  • kein Deployment auslösen,
  • keine weiteren Update-Commands ausführen,
  • verdächtige Tool-Integration stoppen oder deaktivieren.

2. Zustand sichern

  • git status notieren,
  • git diff sichern,
  • betroffene Dateien notieren,
  • Tool, Agent, Command oder Dependency notieren,
  • Zeitpunkt notieren,
  • Logs, Screenshots oder Terminalausgaben sichern, wenn vorhanden.

3. Melden

  • technischen Lead oder Maintainer informieren,
  • kurze Fakten nennen,
  • keine Spekulation als Fakt darstellen,
  • keine Kundenkommunikation ohne Abstimmung starten.

4. Eingrenzen

  • Welche Daten oder Dateien waren betroffen?
  • Wurde etwas geschrieben?
  • Wurde etwas gepusht?
  • Wurde etwas deployed?
  • Wurde etwas an externe Dienste gesendet?
  • Sind Secrets, Dumps, Logs oder Kundendaten betroffen?

5. Entscheiden

  • Tool stoppen oder sperren,
  • Branch isolieren,
  • Merge Request schließen oder markieren,
  • Dependency zurückrollen,
  • Secret rotieren,
  • Deployment stoppen oder zurückrollen,
  • externe Systeme korrigieren,
  • Kunde informieren, wenn notwendig und abgestimmt.

Erste Anlaufstelle

Erste Anlaufstelle bei KI-, Tool- oder Update-Verdacht ist der technische Lead oder Maintainer.

Begründung:

  • Vorfälle sind zuerst technisch einzugrenzen.
  • Schadensbegrenzung und Rollback brauchen technische Entscheidung.
  • Zu frühe breite Kommunikation ohne Fakten erzeugt Chaos.
  • Zu spätes technisches Stoppen vergrößert Schaden.

Eskalationslinie:

  • Entwickler stoppt und sichert Zustand.
  • Technischer Lead oder Maintainer bewertet und begrenzt Schaden.
  • Projektleiter wird informiert, wenn Auswirkung, Kunde, Termin oder Aufwand betroffen sind.
  • Admin, Security oder Datenschutz wird hinzugezogen bei Secrets, Kundendaten, Produktionssystemen oder möglichem Datenabfluss.
  • Kunde wird nur abgestimmt informiert, wenn Kundenauswirkung realistisch ist oder vertraglich nötig.

Kernregel:

Erst technisch begrenzen, dann breiter eskalieren.

Was der Entwickler sofort tun darf

Sofort erlaubt:

  • Tool oder Agent stoppen,
  • keine weiteren Aktionen ausführen,
  • aktuellen Zustand sichern,
  • Netzwerk- oder Tool-Zugriff deaktivieren, wenn offensichtlich riskant,
  • Branch nicht pushen,
  • betroffene Commands notieren,
  • technischen Lead informieren.

Nicht ohne technischen Lead:

  • Dateien aufräumen,
  • Git-History ändern,
  • Force Push,
  • Secrets löschen und so tun, als wäre nichts passiert,
  • Deployment rollbacken, wenn kein klar definierter Ablauf existiert,
  • Kundenkommunikation starten,
  • Tool weiter testen,
  • weitere Dependencies aktualisieren,
  • weitere Agentenläufe starten.

Wandregel:

Nicht aufräumen, bevor der Zustand gesichert ist.

Rollback und Wiederherstellung

Rollback ist technisch teilweise möglich, aber noch nicht als bekannte Routine dokumentiert.

Das ist riskant, weil im Vorfall Zeitdruck entsteht.

Projekt-Minimum für Rollback:

  • Wer ist technischer Lead?
  • Wie stoppt man Deployment?
  • Wie rollt man Release-Folder zurück?
  • Gibt es DB-Migrationen mit Rollback-Risiko?
  • Wo liegen relevante Logs?
  • Welche Secrets müssten rotiert werden?
  • Wer darf Git-History oder Force Push entscheiden?
  • Wer informiert Projektleitung oder Kunde?
  • Wo wird der Vorfall dokumentiert?

Rollback nach Bereich:

  • Lokal: erst Zustand sichern, dann gezielt zurücksetzen.
  • Git/MR: kein Force Push ohne technischen Lead.
  • Deployment: vorhandenen Release-Folder-Fallback nutzen, Datenbank separat bewerten.
  • Dependencies: Lockfile prüfen, Version zurückpinnen, MR isolieren.
  • Secrets: nicht nur Datei löschen, sondern Secret rotieren oder Rotation bewusst begründen.
  • Trello/Jira: Änderung nachvollziehbar korrigieren, nicht still löschen, wenn Nachvollziehbarkeit wichtig ist.

Kernregel:

Rollback darf nicht erst im Vorfall erfunden werden.

Secrets und Datenabfluss

Wenn ein Secret, Dump, Log oder Kundendaten in KI-Kontext gelangt sind, reicht Löschen aus Chat oder Datei nicht.

Regel:

Wenn ein Secret im KI-Kontext war, gilt es als kompromittiert, bis fachlich anders bewertet.

Praktische Maßnahmen:

  • Nutzung sofort stoppen,
  • betroffene Daten benennen,
  • Secret rotieren, wenn Secret betroffen ist,
  • bewusst dokumentieren, wenn Rotation nicht erfolgt,
  • Logs oder Dumps lokal entfernen oder verschieben,
  • .aiignore und Projektregeln nachziehen,
  • Tool-Kontext oder History löschen, wenn möglich,
  • Anbieter- oder Tool-Retention prüfen,
  • Datenschutz, Security oder Projektleitung einbeziehen, wenn Kundendaten betroffen sind.

Da Secrets projektweise unterschiedlich verwaltet werden, braucht jedes Projekt wenigstens eine kurze Prozessnotiz:

  • welche Secret-Arten existieren,
  • wo sie verwaltet werden,
  • wer sie rotieren darf,
  • wie schnell Rotation praktisch möglich ist,
  • welche Systeme nach Rotation angepasst werden müssen,
  • welche Deployments danach nötig sind.

Die Notiz darf keine Secret-Werte enthalten.

Incident-Notiz

Jeder relevante KI-/Tool-/Update-Verdacht bekommt eine kurze Incident-Notiz.

Das ist keine Bürokratie, sondern Faktensicherung.

Minimalfelder:

  • Datum und Uhrzeit,
  • Projekt,
  • gemeldet von,
  • Tool, Agent, Dependency oder System,
  • was passiert ist,
  • was sofort gestoppt wurde,
  • welche Dateien, Daten oder Systeme betroffen sind,
  • ob gepusht, deployed oder extern geschrieben wurde,
  • erste Bewertung: niedrig, mittel oder hoch,
  • Maßnahmen,
  • offene Punkte,
  • Entscheidung: geschlossen, beobachten oder eskalieren.

Kernregel:

Was nicht dokumentiert ist, kann später nicht sauber bewertet werden.

Klassifizierung

Niedrig

Merkmale:

  • nur lokal,
  • kein Kundendaten- oder Secret-Bezug,
  • nichts gepusht,
  • nichts deployed,
  • keine externen Systeme geändert.

Eskalation:

  • Entwickler,
  • technischer Lead oder Maintainer.

Mittel

Merkmale:

  • Projektcode betroffen,
  • MR/PR oder Branch betroffen,
  • falsche Dependency, Rule oder Config im Branch,
  • Trello-/Jira-Entwurf falsch geschrieben,
  • noch keine Produktion,
  • keine Kundendaten.

Eskalation:

  • technischer Lead oder Maintainer,
  • Projektleiter.

Hoch

Merkmale:

  • Secret, Dump, Log oder Kundendaten betroffen,
  • Push in geteiltes Repo mit sensiblen Inhalten,
  • Deployment oder Produktion betroffen,
  • externe Systeme wirksam geändert,
  • mögliches Supply-Chain- oder kompromittiertes Update,
  • unklare Datenübertragung an externen Anbieter.

Eskalation:

  • technischer Lead oder Maintainer,
  • Projektleiter,
  • Admin, Security oder Datenschutz,
  • Kunde, falls notwendig und abgestimmt.

P0-No-Gos

Kein Weiterarbeiten mit verdächtigem Tool.

Keine weiteren Commands, Updates, Pushes oder Deployments nach Verdacht.

Keine Spuren löschen oder Zustand ungesichert verändern.

Kein Force Push oder History-Umschreiben ohne technischen Lead.

Kein Verschweigen von möglichem Datenabfluss.

Keine Secrets nur löschen, ohne Rotation oder bewusste Entscheidung.

Keine Kundenkommunikation ohne abgestimmte Faktenlage.

Kein Ignorieren unerwarteter Schreib-, Sende- oder Veröffentlichungsaktionen.

Kein Rollback ohne Scope, wenn Produktion, Datenbank oder externe Systeme betroffen sind.

Mindeststandard

Für KI-/Tool-/Update-Vorfälle gilt mindestens:

  • Stop-Regel kennen,
  • technischer Lead oder Maintainer als erste Anlaufstelle,
  • Zustand sichern,
  • kurze Incident-Notiz erstellen,
  • Vorfall niedrig, mittel oder hoch einstufen,
  • Rollback-Minimum projektweise kennen,
  • Secret-Rotation projektweise klären,
  • Tool-Liste und Projektregeln nachziehen,
  • aus Vorfällen Regeln und Checklisten verbessern.

Teamentscheidung

Bei Verdacht wird gestoppt, gesichert und gemeldet. Es wird nicht weiterprobiert.

Erste Anlaufstelle ist der technische Lead oder Maintainer.

Entwickler dürfen sofort Tool oder Agent stoppen und Zustand sichern, aber nicht eigenmächtig aufräumen, History ändern, Force Push ausführen oder Kundenkommunikation starten.

Rollback und Secret-Rotation müssen projektweise mindestens als Prozess bekannt sein.

Wenn ein Secret im KI-Kontext war, gilt es als kompromittiert, bis fachlich anders bewertet.

Jeder relevante KI-/Tool-/Update-Verdacht bekommt eine kurze Incident-Notiz.

Vorfälle werden einfach in niedrig, mittel und hoch eingestuft und entsprechend eskaliert.

Wandregeln

Bei Verdacht stoppen, sichern, melden, nicht weiterprobieren.

Nicht aufräumen, bevor der Zustand gesichert ist.

Rollback darf nicht erst im Vorfall erfunden werden.

Secret im KI-Kontext heißt: erst kompromittiert annehmen.

Erst technisch begrenzen, dann breiter eskalieren.

Offene Teamfragen

  • Wer ist je Projekt technischer Lead oder Maintainer für Vorfälle?
  • Wo wird die Incident-Notiz abgelegt?
  • Welche Projekte haben bereits bekannten Release-Folder-Rollback?
  • Welche Projekte haben DB-Migrationen ohne klares Rollback?
  • Wo ist je Projekt dokumentiert, wer Secrets rotieren darf?
  • Wer entscheidet Kundenkommunikation bei möglichem Datenabfluss?
  • Welche Logs dürfen im Vorfall gesichert werden, ohne neue Datenschutzprobleme zu erzeugen?