Zurück zur Übersicht

    Die ersten 24 Stunden nach einem Agenten-Vorfall

    Ein Agent mit gültigen Zugangsdaten tut etwas, das niemand autorisiert hat. Was in den nächsten 24 Stunden passiert, entscheidet über Schaden und Meldefähigkeit — und klassische Playbooks greifen daneben, weil sie den Host isolieren wollen statt die Identität zu widerrufen. Der Ablauf Stunde für Stunde, mit der zweiten Uhr, die in Deutschland parallel läuft: 24 Stunden Erstmeldung nach NIS-2, Protokollierungspflicht nach Artikel 12 der KI-Verordnung.

    Veröffentlicht am von J. Benjamin Espagné
    ai-securityincident-responseagentennis2ai-actowasp-asiprompt-injectiondfir

    Die meiste Literatur zu Agenten-Sicherheit besteht aus Taxonomien, Governance-Prinzipien und dem Aufruf, verantwortungsvolle KI-Praktiken zu etablieren. Das trägt eine Vorstandsvorlage. Es hilft niemandem um 2:30 Uhr, wenn ein autonomer Agent mit gültigen Zugangsdaten gerade etwas getan hat, das niemand autorisiert hat.

    So beginnt ein Beitrag von Ravindra Annam, der Ende August bei CSO Online erschienen ist. Er spielt den ersten Tag Stunde für Stunde durch, statt ein weiteres Rahmenwerk zu formulieren. Wir greifen das auf und ergänzen, was in der angelsächsischen Diskussion durchgängig fehlt: In Deutschland läuft parallel zur technischen Uhr eine regulatorische. Und beide sind langsamer als der Agent.

    Warum die Uhr bei Agenten anders läuft

    Klassische Incident Response ist auf zwei Annahmen gebaut: Ein menschlicher Angreifer bewegt sich in menschlichem Tempo, oder Schadsoftware führt einen festen Befehlssatz aus. Agentische Systeme brechen beide Annahmen gleichzeitig.

    GTG-1002. Anthropic dokumentierte im November 2025 eine Kampagne, in der eine staatlich unterstützte chinesische Gruppe Claude Code gegen rund 30 Organisationen einsetzte. Schätzungen zufolge übernahm das System 80 bis 90 Prozent der operativen Arbeit, mit lediglich vier bis sechs menschlichen Entscheidungspunkten pro Kampagne. Das Bemerkenswerte daran ist nicht die Zuordnung, sondern die Taktzahl. Eine Phishing-Mail liegt einen Tag im Postfach, bevor jemand klickt. Diese Kompromittierung skaliert sich selbst, während die Rufbereitschaft noch das Telefon sucht.

    EchoLeak (CVE-2025-32711, CVSS 9.3). Aim Security offenbarte im Juni 2025 eine Zero-Click-Prompt-Injection in Microsoft 365 Copilot. Eine einzige präparierte E-Mail — Anweisungen versteckt als HTML-Kommentar oder weiß auf weiß — genügte, um beim routinemäßigen Zusammenfassen Inhalte aus OneDrive, SharePoint und Teams an einen fremden Server abfließen zu lassen. Ohne jede Nutzerinteraktion. Kein Link zum Detonieren, kein Anhang zum Sandboxen. Nur Inhalt, den der Agent zu lesen gebaut war. Der Payload umging Microsofts XPIA-Klassifikator, indem er auf explizit an KI gerichtete Formulierungen verzichtete.

    Es blieb nicht der einzige Fall dieser Klasse: CamoLeak (CVE-2025-59145, CVSS 9.6) traf GitHub Copilot Chat, gefunden im Juni 2025, gepatcht im August, offengelegt im Oktober.

    Salesloft Drift. Zwischen dem 8. und 18. August 2025 nutzte der Akteur UNC6395 gestohlene OAuth-Tokens der Drift-Integration, um sich als vertrauenswürdige Anwendung gegenüber Salesforce auszugeben. Über 700 Organisationen waren betroffen. Kein Exploit, kein Phishing, kein kompromittiertes Benutzerkonto — automatisierte SOQL-Abfragen und Massenexporte mit eigenen User-Agent-Strings, die wie eine legitime Integration aussahen. Anschließend durchsuchten die Angreifer die Beute nach weiteren Zugangsdaten, Tokens und Schlüsseln.

    Das strukturelle Merkmal dieser drei Fälle verändert die Vorgehensweise am ersten Tag: Der Angreifer kann ein Satz Anweisungen in einem Dokument sein, eine vergiftete Werkzeugantwort oder ein manipulierter Gedächtnisspeicher — keine Person an einer Tastatur. Eindämmung bedeutet, eine Identität zu widerrufen und Werkzeugzugriffe zu kappen. Sie bedeutet nicht, einen Host zu isolieren. Jedenfalls nicht zuerst. Annam berichtet, er habe Kollegen mitten im Vorfall korrigieren müssen, die reflexhaft nach dem Netzwerkkabel griffen.

    Die zweite Uhr: was NIS-2 und der AI Act verlangen

    Hier weicht die deutsche Lage von der amerikanischen ab, und zwar erheblich.

    NIS-2 verlangt von betroffenen Einrichtungen eine Erstmeldung binnen 24 Stunden nach Kenntnis eines erheblichen Sicherheitsvorfalls und eine Folgemeldung binnen 72 Stunden. Die Frist beginnt mit der Kenntnis, nicht mit der Aufklärung. Wer erst meldet, wenn er weiß, was passiert ist, meldet zu spät.

    Der EU AI Act verlangt in Artikel 12 die automatische Protokollierung von Ereignissen über die Lebensdauer eines Hochrisiko-Systems. Für Agenten heißt das: Die Tool-Call-Historie ist kein Debug-Artefakt, sondern ein Aufzeichnungsgegenstand. Artikel 15 adressiert Genauigkeit, Robustheit und Cybersicherheit, Artikel 14 die menschliche Aufsicht.

    Dazu kommen Artikel 30 DSGVO — das Verzeichnis von Verarbeitungstätigkeiten erstreckt sich sinngemäß auf das, worauf ein Agent zugegriffen hat und warum — sowie DORA für den Finanzsektor.

    Die praktische Folge: Ein Agenten-Vorfall erzeugt eine Meldepflicht, deren Erfüllung eine Beweislage voraussetzt, die die meisten Organisationen für Agenten nicht erheben. Ohne vollständige Tool-Call-Protokolle mit Parametern, Identitäten und Ergebnissen ist die 72-Stunden-Folgemeldung eine Vermutung mit Briefkopf.

    Der Ablauf, Stunde für Stunde

    Stunde 0 — Erkennen, was hier eigentlich vorliegt

    Die Uhr startet mit der Erkennung, und genau dort geht die meiste Zeit verloren. Agenten-Vorfälle lösen die Alarme nicht aus, auf die ein SOC getunt ist.

    Worauf zu achten ist: statistisch auffälliges Tool-Call-Volumen aus einer einzelnen Agenten-Identität. Ein Agent, der außerhalb seines deklarierten Aufgabenbereichs handelt — ein Zusammenfassungs-Agent, der plötzlich eine Dateifreigabe durchsucht. Ausgaben, die sich auf Anweisungen beziehen, die kein Mensch gegeben hat.

    Die Frage in dieser Phase ist Triage, nicht Diagnose: Handelt es sich um eine kompromittierte Sitzung, um geteilte Zugangsdaten, oder um einen systemischen Injection-Vektor, der in einem Dokument liegt, das jeder Agent lesen könnte?

    Stunde 0 bis 1 — Eindämmung über die Identität, nicht über den Host

    Hier scheitern klassische Playbooks am häufigsten. Ein gezogenes Netzwerkkabel hilft nicht, wenn der Schaden bereits über einen API-Aufruf drei Systeme weiter entstanden ist.

    Konkret in dieser Reihenfolge: Zugangsdaten, API-Schlüssel und OAuth-Tokens des Agenten widerrufen oder sperren, wie bei einem kompromittierten Dienstkonto. Aktive Sitzung beenden, sofern die Orchestrierungsschicht das hergibt. Gedächtnisspeicher und Tool-Call-Historie einfrieren, nicht löschen. Läuft der Agent über einen Broker oder ein Gateway, dort die registrierten Werkzeuge deaktivieren, statt einzelne nachgelagerte Systeme abzuklappern.

    Das Einfrieren statt Löschen ist der Punkt, an dem technische und regulatorische Uhr sich berühren. Was in dieser Stunde verloren geht, fehlt in der 72-Stunden-Meldung — und in jedem späteren Verfahren. Beweissicherung geht der Wiederherstellung vor, immer.

    Stunde 1 bis 4 — Wirkungsradius bestimmen

    Jetzt geht es darum, was der Agent tatsächlich berührt hat. Vollständiges Tool-Call-Protokoll ziehen: jeder aufgerufene Dienst, jeder übergebene Parameter, jede empfangene Antwort. Das gegen die Berechtigungen des Agenten spiegeln — was konnte er erreichen gegenüber dem, was er erreicht hat.

    Ein Punkt, der häufig übersehen wird: Hat der Agent unterwegs eigene Artefakte erzeugt? Eine geplante Aufgabe, eine Weiterleitungsregel, einen neuen API-Schlüssel. Autonome Agenten sind in Persistenz oft besser als die Menschen, die sie gebaut haben.

    Und wenn der Einstiegsvektor nach indirekter Prompt Injection aussieht: Welche anderen Sitzungen haben denselben vergifteten Inhalt gelesen? Das ist selten ein Einzelfall.

    Eine Warnung zur Protokollauswertung, die aus eigener Erfahrung stammt und über den Ausgangsbeitrag hinausgeht: Tool-Antworten sind nicht automatisch wahr. Wir hatten diese Woche im eigenen Betrieb einen Endpunkt, der Schreibvorgänge mit HTTP 200 und vollständigem Datensatz quittierte — und nichts schrieb. Für die Forensik heißt das: Ein Protokolleintrag über eine erfolgreiche Aktion belegt, dass der Agent eine Erfolgsmeldung erhalten hat. Nicht, dass die Aktion stattfand. Und umgekehrt kann eine Aktion stattgefunden haben, deren Rückmeldung verloren ging. Wirkungsradius wird am Zielsystem verifiziert, nicht am Agentenprotokoll.

    Stunde 4 bis 8 — Melden, bevor Gewissheit besteht

    Rechtsabteilung, Datenschutz und Geschäftsführung brauchen eine erste Unterrichtung deutlich vor Abschluss der Forensik. Auf Gewissheit zu warten, ist der Weg, auf dem aus einem Vorfall ein Offenlegungsversäumnis wird.

    Drei Dinge gehören in diese Unterrichtung: worauf der Agent zugreifen konnte, was die Beweislage aktuell zeigt, worauf er tatsächlich zugegriffen hat, und was noch unbekannt ist. Die dritte Kategorie explizit zu benennen, ist keine Schwäche — sie ist die Voraussetzung dafür, dass die spätere Korrektur keine Falschmeldung war.

    In dieser Phase fällt auch die Entscheidung, ob andere Agenten mit derselben Basiskonfiguration oder Werkzeuganbindung vorsorglich pausiert werden. Ein verwundbares Muster repliziert sich über eine ganze Agentenflotte, bevor jemand es bemerkt. OWASP führt das als ASI08, Cascading Agent Failures.

    Für NIS-2-pflichtige Einrichtungen liegt hier der Übergabepunkt an die Meldekette. Die 24-Stunden-Erstmeldung ist bewusst kurz gehalten: erheblicher Vorfall ja oder nein, erste Einschätzung, ob rechtswidrige Handlung vermutet wird, grenzüberschreitende Auswirkung. Sie ist keine forensische Analyse und soll keine sein.

    Stunde 8 bis 16 — Die Entscheidungskette rekonstruieren

    Das ist der Teil, der sich von klassischer Forensik grundlegend unterscheidet. Es geht nicht darum, zu rekonstruieren, was auf einer Festplatte geschah, sondern warum das Modell entschied, es zu tun.

    Vollständige Prompt- und Antwortkette durchgehen, einschließlich allem, was der Agent vor der auffälligen Aktion abgerufen hat. Ziel ist die konkrete Anweisung — sichtbar oder versteckt —, die sein Verhalten umgelenkt hat.

    Eine Unterscheidung entscheidet über die Gegenmaßnahme: Zeigt die Ausgabe des Agenten, dass er die Anweisung als verdächtig erkannt und trotzdem ausgeführt hat, liegt eine Guardrail-Lücke vor. Hat er sie nie als auffällig markiert, ist es eine Erkennungslücke. Der Fix sieht in beiden Fällen anders aus.

    Stunde 16 bis 24 — Wiederherstellen, aber vorher etwas ändern

    Ein Agent wird nicht in seine vorherige Konfiguration zurückversetzt. So kommt derselbe Vorfall binnen einer Woche wieder.

    Konkret: den spezifischen Vektor schließen, den Ingestionspfad bereinigen, den Werkzeug-Scope verengen oder eine Freigabestufe für die missbrauchte Aktionsklasse einziehen. Zugangsdaten neu ausstellen — mit engeren Berechtigungen als vorher, nie mit identischen.

    Und die 24-Stunden-Zusammenfassung schreiben, solange die Zeitachse frisch ist. Sie ist die Eingangsgröße für die Nachbetrachtung und häufig für die behördliche oder kundenseitige Meldung.

    Der Rahmen, an dem sich das ausrichten lässt

    Seit Dezember 2025 gibt es dafür eine gemeinsame Sprache. Die OWASP Top 10 for Agentic Applications (2026), veröffentlicht am 10. Dezember 2025 und von über hundert Fachleuten begutachtet, benennt zehn Risikokategorien von ASI01 bis ASI10: Agent Goal Hijack, Tool Misuse, Identity and Privilege Abuse, Agentic Supply Chain Compromise, Unexpected Code Execution, Memory and Context Poisoning, Insecure Inter-Agent Communication, Cascading Agent Failures, Human-Agent Trust Exploitation und Rogue Agents.

    Das Leitprinzip heißt Least Agency — das agentische Gegenstück zu Least Privilege. Nicht nur: Worauf darf der Agent zugreifen? Sondern: Wie viel Handlungsspielraum braucht er überhaupt?

    Die Liste ersetzt die OWASP Top 10 für LLM-Anwendungen nicht, sie erweitert sie. Die meisten Agentensysteme sind auch LLM-Anwendungen und erben deren Risiken.

    Parallel dazu hat NIST über sein Center for AI Standards and Innovation am 17. Februar 2026 die AI Agent Standards Initiative gestartet. Das begleitende NCCoE-Konzeptpapier vom 5. Februar 2026 benennt vier Fokusbereiche, die faktisch die Mindestarchitektur für jeden produktiven Agenten beschreiben: Identifikation, Autorisierung, Zugriffsdelegation, Protokollierung. Der adressierte Missstand ist präzise formuliert — Agenten werden üblicherweise als generische Dienstkonten behandelt, ohne eigene Identität, ohne eigene Autorisierung, ohne Zurechenbarkeit.

    Wer diese vier Bereiche heute sauber baut, behandelt die spätere NIST-Veröffentlichung als Bestätigung statt als Anlass zur Nachrüstung.

    Was vor dem Vorfall geklärt sein muss

    Aus den Phasen oben ergeben sich Voraussetzungen, die sich um 2:30 Uhr nicht mehr schaffen lassen:

    1. Agenten-Inventar. Welche Agenten laufen, mit welcher Identität, mit welchen Werkzeugen, mit welchen Berechtigungen? Ein AIBOM — die Stückliste über Agenten, Werkzeuge und MCP-Server — wird gerade zum erwarteten Prüfungsartefakt. Prüfer fragen inzwischen nach Aktivitätsprotokollen, Berechtigungsprüfungen und Abschaltprozeduren.
    2. Eigene Identität pro Agent. Kein geteiltes Dienstkonto. Ohne unterscheidbare Identität ist Eindämmung über die Identität nicht möglich — und genau die ist der erste Schritt.
    3. Ein Notaus, der getestet ist. Wer kann einen Agenten stilllegen, mit welchem Befehl, in welcher Zeit, auch am Sonntag um drei?
    4. Tool-Call-Protokollierung ins SIEM. Welches Werkzeug, welche Parameter, welche Identität, welches Ergebnis. Ohne diese Telemetrie ist der Agent im Monitoring unsichtbar, und nach dem Vorfall gibt es nichts zu rekonstruieren. Der EU AI Act verlangt das für Hochrisiko-Systeme ohnehin.
    5. Freigabestufen für irreversible Aktionsklassen. Löschungen, Massenänderungen, Datenexporte, ausgehende Kommunikation, Zahlungen. Nicht wegen des Angreifers, sondern wegen der irreversiblen Fehlentscheidung. Der Fall des Handelsunternehmens Step Finance, das im Januar 2026 nach Verlusten im zweistelligen Millionenbereich den Betrieb einstellte, wird darauf zurückgeführt, dass Handelsagenten größere Transfers ohne menschliche Freigabe ausführen konnten.
    6. Geübte erste 24 Stunden. Nicht als Prinzipienpapier, sondern als Planspiel gegen die Uhr — mit der Meldekette als Teil der Übung, nicht als Anhang.

    Was diesen Fall von einem klassischen Vorfall unterscheidet

    Drei Sätze, die sich als Merkregel eignen:

    Eindämmung erfolgt über die Identität, nicht über den Host. Das Netzwerkkabel ist bei einem Agenten fast immer die falsche erste Bewegung.

    Beweissicherung geht dem Patch voraus. Gedächtnisspeicher und Tool-Call-Historie einfrieren, bevor irgendetwas repariert wird. Was gelöscht ist, fehlt in der Meldung.

    Wiederhergestellt wird nie in die Konfiguration, die gerade versagt hat. Enger, nicht identisch.

    Der Rest ist Übung. Annams Schlussfolgerung deckt sich mit unserer Erfahrung: Die Organisationen, die einen Vorfall dieser Klasse gut überstanden haben, hatten selten die beste Risiko-Taxonomie an der Wand. Sie hatten die ersten 24 Stunden vorher schon einmal durchgespielt.

    Quellen

    Die Phaseneinteilung folgt Annams Beitrag. Die regulatorische Einordnung nach NIS-2 und KI-Verordnung, die Verifikation der genannten Vorfälle, die Ergänzungen zu OWASP ASI und NIST sowie der Abschnitt zum Protokollvertrauen stammen von uns.