AI Security · 12 Min.
AI Agent Incident Response: Was passiert, wenn ein KI-Agent falsch handelt?
Wer KI-Agenten produktiv betreibt, braucht nicht nur Guardrails. Er braucht einen Plan für den Fall, dass etwas schiefgeht.
SYSTEMS Grafik zu AI Agent Incident Response: Risk -> Guardrail -> Audit. Fokus: Wie Unternehmen reagieren, wenn ein KI-Agent falsche Aktionen ausführt oder Sicherheitsgrenzen verletzt.
Kurzfassung
Produktive Agenten brauchen Incident Response wie andere Systeme auch. Wichtige Bausteine sind Logs, Rechteentzug, Kill Switch, Ursachenanalyse und Evals. Der Incident muss in bessere Guardrails zurückfliessen.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknüpfe es mit den nächsten Architekturentscheidungen.
Warum Incidents eingeplant werden müssen Ein Agent kann falschen Kontext nutzen, ein falsches Tool wählen oder auf Prompt Injection reagieren. Gute Architektur reduziert das Risiko, eliminiert es aber nicht.
Deshalb braucht es einen Plan vor dem Vorfall.
Stand Mai 2026: Agenten brauchen IR wie Software plus AI-spezifische Spuren NIST SP 800-61 Rev. 3 ordnet Incident Response in das Cybersecurity-Risikomanagement ein. Für KI-Agenten bleibt der klassische Ablauf aus Vorbereitung, Erkennung, Analyse, Containment, Wiederherstellung und Lessons Learned gültig, aber die Beweise sehen anders aus. NISTs GenAI-Profil nennt After-Action-Reviews für GAI-Incidents und Updates an Incident-Response- und Disclosure-Prozessen.
Neben klassischen Logs braucht man:
Ohne diese Spuren kann niemand sauber rekonstruieren, warum der Agent falsch gehandelt hat.
Tracing hilft dabei, aber es ersetzt Incident Response nicht. Je nach Anbieter, Datenschutzmodus oder Zero-Data-Retention-Setup müssen Teams eigene Logs, Redaction und Aufbewahrungsregeln bauen.
Prompt- und Policy-Version. Modell- und Tool-Version. Agentenrolle und User-Kontext. Tool-Call-Trace. Eingabequellen und Datenklasse. Approval-Status. Guardrail-Entscheidungen. Output, Aktion und Downstream-Effekt. Eval- und Regressionsergebnis nach dem Fix. Die ersten Minuten Zuerst: Agent stoppen, Rechte entziehen, Lauf sichern, betroffene Daten oder Aktionen identifizieren. Dann erst wird analysiert.
Wer keine Logs hat, kann nur raten.
Die ersten 30 Minuten:
Wichtig: Nicht sofort Prompts überschreiben, Logs löschen oder Tools neu deployen. Erst Beweise sichern.
Agent oder Workflow pausieren. API-Key, MCP-Connector oder Tool-Scope temporär entziehen. betroffene Runs, Traces und Logs sichern. Schreibaktionen einfrieren, wenn Datenkorruption möglich ist. betroffene Kunden, Datensätze, Systeme und Zeitfenster bestimmen. Owner, Security, Legal, Support und Fachbereich informieren. Workaround aktivieren: Mensch übernimmt oder Prozess geht in Read-only. Ursachenanalyse War der Prompt schlecht, das Tool zu breit, der Kontext manipuliert, die Freigabe falsch oder der Eval-Satz unvollständig? Jede Ursache braucht eine andere Massnahme.
Ein Incident ist ein Lernsignal.
Die Root-Cause-Matrix:
OpenAI Agent-Builder-Safety empfiehlt unter anderem strukturierte Outputs, Tool Approvals, Guardrails und Trace Grading. Das sind nicht nur Praeventionsmassnahmen, sondern auch Reparaturpunkte nach einem Incident.
Prompt: Regel fehlt, Regel widerspricht sich, Beispiel führt in die falsche Richtung. Tool: Tool ist zu breit, Parameter sind unvalidiert, Schreibaktion ist zu leicht erreichbar. Kontext: falsche Quelle, veraltete Daten, Prompt Injection in Dokument oder CRM-Notiz. Rechte: Agent durfte zu viel lesen oder schreiben. Approval: Mensch sah nicht genug Information für Freigabe. Modell: Modellwechsel, Regression oder instabile Tool-Auswahl. Eval: Testfall fehlte oder Grader prüfte nur Output, nicht Tool-Pfad. Betrieb: Logging, Alerting oder Kill Switch fehlte. Containment für Agenten Bei klassischen Systemen trennt man Hosts, Accounts oder Netzwerke. Bei Agenten trennt man zusätzlich Autonomie:
Computer-Use-Workflows haben eigene Sicherheitschecks wie `pending_safety_checks`. Wenn solche Checks feuern, gehört ein Mensch in den Loop.
Bei MCP -Setups gehören ausserdem Tool-Call-Logs, SIEM-Anbindung, Alarmierung auf ungewöhnliche Muster und Redaction von Secrets oder PII in den Plan. OWASP nennt Token-/Secret-Exposure, Shadow MCP Servers und Context Over-Sharing als eigene Risikoklassen.
Schreibtools auf Approval setzen. MCP-Server oder Connector deaktivieren. allowed tools auf read-only reduzieren. riskante Domains oder Aktionen blockieren. Prompt-Version zurückrollen. Modell- oder Workflow-Version einfrieren. Datenquelle aus dem Kontext entfernen. menschlichen Handoff erzwingen. Kommunikation Nicht jeder Agentenfehler ist ein meldepflichtiger Sicherheitsvorfall. Aber jedes Team braucht vorher Kriterien:
Je nach Antwort brauchen Support, Kundenkommunikation, Datenschutz, Security oder Management unterschiedliche Informationen. Gute Kommunikation ist konkret: Was ist passiert, was ist betroffen, was wurde gestoppt, was wird korrigiert, was ändert sich dauerhaft?
Wurden Kundendaten offengelegt? Wurden Daten verändert oder gelöscht? Wurde eine externe Nachricht gesendet? Gab es finanzielle, rechtliche oder vertragliche Auswirkung? Ist ein Kunde direkt betroffen? Ist der Fehler reproduzierbar? Post-Incident: Aus Fehlern Tests machen Ein Incident ist erst geschlossen, wenn er in bessere Kontrollen übersetzt wurde:
Sonst ist es nur ein behobener Einzelfall.
neuer Eval-Fall. neuer Trace-Grader. engeres Tool-Schema. zusätzliche Approval-Regel. Logging-Feld ergänzt. Runbook angepasst. Owner benannt. nächster Review-Termin gesetzt. Der SYSTEMS-Blick Wir bauen Incident Response in die Agentenarchitektur ein. Logs, Rechte, Stop-Regeln und Review sind nicht optional.
So wird ein Fehler kontrollierbar statt existenziell: vorbereitet, nachvollziehbar, begrenzbar und in bessere Agenten-Evals übersetzt.
