Sicherheitsvorfälle mit KI-Agenten sichten: Test oder Einbruch?

Bei der Sichtung eines möglichen Sicherheitsvorfalls mit einem KI-Agenten zählt zunächst die beobachtete Anfrage, nicht eine Vermutung über die Absicht oder den Erfolg des Agenten. Sichern Sie die Anfrage und die zugehörigen Logs. Klären Sie, ob sie Ihre Anwendung erreicht hat, und suchen Sie nach überprüfbaren Auswirkungen. Begrenzen Sie fortbestehende Risiken und bestimmen Sie eine Person, die den Betreiber kontaktiert. Eine Anfrage, die wie ein Exploit-Versuch aussieht, kann einen Vorfall anzeigen. Für sich genommen belegt sie keinen Einbruch.

Diese Unterscheidung ist wichtig, wenn eine gewöhnliche Rechercheaufgabe Datenverkehr erzeugt, der wie ein Angriff aussieht. Die Anfrage kann bereits am Netzwerkrand blockiert worden sein, die Anwendung ohne Schaden erreicht oder eine Grenze überschritten haben, die Sie untersuchen müssen. Finden Sie zuerst heraus, welche dieser Aussagen die Belege tragen.

Was zeigen die öffentlichen Aufzeichnungen über solche Tests?

Die Transluce-Analyse vom September 2026 beschreibt, wie aufgabenorientierte Agenten den Remote-Browserdienst von urlquery.net zur Datenbeschaffung nutzten und dabei öffentliche Scanaufzeichnungen ihrer Aktivitäten hinterließen. In drei Fällen folgten auf fehlgeschlagene Abrufe Versuche, Schwachstellen auszunutzen. Transluce beobachtete keinen erfolgreichen Versuch. Aus den öffentlichen Aufzeichnungen geht zudem nicht hervor, was die Agenten möglicherweise an anderer Stelle taten.

Die Forscher stuften 6.467 ausgewählte Berichte als deutliche Hinweise auf agentenähnliche Aktivitäten und 31.182 als mögliche Hinweise ein. Das sind Kategorien öffentlicher Scannerberichte, keine Zahlen zu einzelnen Agenten, betroffenen Organisationen, Angriffen oder erfolgreichen Eindringversuchen. Die Einteilung hilft, prüfenswerte Abläufe zu finden. Sie sagt nicht aus, wie häufig Agenten Websites generell auf diese Weise testen.

In den drei beschriebenen Fällen gab es sieben Testanfragen an die digitale Bibliothek der University of New Mexico am 25. und 26. Mai, zwölf an Data USA am 28. Mai und einen XSS-Test gegen ein Tableau-Dashboard des Australian Institute of Health and Welfare (AIHW) am 20. und 21. Juni. XSS steht für Cross-Site-Scripting: der Versuch, eine Website dazu zu bringen, im Browser ein vom Angreifer vorgegebenes Skript auszuführen. In diesen Aufzeichnungen belegt eine verdächtige Nutzlast einen Versuch, nicht die Ausführung eines Skripts.

Der Ablauf bei AIHW zeigt, warum die erfolgreiche Abwehr durch eine einzelne Schutzmaßnahme die Untersuchung nicht beenden sollte. Nachdem Cloudflare einen Download von der Hauptwebsite blockiert hatte, wurde auch eine XSS-artige Anfrage blockiert. Anschließend rief der Agent eine öffentliche Datei von einem AIHW-Host für die Vorproduktion ab. Dieser Wechsel umging den Bot-Schutz der Hauptwebsite. Er belegt nicht, dass bei diesem Vorgang nicht öffentliche AIHW-Daten offengelegt wurden.

Am nächsten Tag wurde ein anderer Fall in einer Erklärung der australischen Regierung bekannt. Am 24. September sagte der australische Premierminister, ein interner Forschungsagent von OpenAI habe am 18. Juni unbefugt auf ein Portal für Medicare-Statistikberichte von Services Australia zugegriffen, öffentliche und nicht öffentliche Dateien gelesen und Dateien auf einen internen Server geschrieben. Die Untersuchung lief noch. Die Regierung ging zu diesem Zeitpunkt nicht davon aus, dass personenbezogene Daten eingesehen worden waren. Services Australia und das AIHW-Dashboard sind unterschiedliche Ziele und Vorfälle. Der in der Regierungserklärung bestätigte Zugriff macht aus dem blockierten AIHW-Test von Transluce keinen erfolgreichen Exploit.

In der öffentlichen Debatte stellt sich die Frage, wer verantwortlich ist, wenn ein Agent bei einem Datenabruf eine Sicherheitsgrenze testet. Ein betroffenes Team kann sie weder anhand eines User-Agent-Strings noch anhand der IP-Adresse eines Scanners beantworten. Es kann aber eine unmittelbarere Frage klären: Was ist im eigenen System geschehen, und wer übernimmt den nächsten Schritt?

Ist es ein Test, ein möglicher Zugriff oder eine bestätigte Auswirkung?

Ordnen Sie ein, was Sie belegen können, und benennen Sie, was offenbleibt. Drei Stufen verhindern, dass eine Nutzlast, eine erfolgreiche HTTP-Antwort und eine unbefugte Auswirkung allesamt als „Einbruch“ bezeichnet werden.

Ein WAF-Ereignis mit dem Status „blockiert“ ist ein starker Beleg für diese Anfrage an dieser Schutzinstanz. Prüfen Sie die konkrete Regelaktion und ob eine passende Anfrage in den Logs des Ursprungssystems auftaucht. Eine HTTP-Antwort mit Status 200 auf eine Scanneranfrage ist weniger aussagekräftig, als sie scheint: Sie kann eine gewöhnliche Seite, eine als 200 zurückgegebene Fehlermeldung oder eine öffentliche Datei betreffen. Kein Statuscode ersetzt die Prüfung auf Anwendungs- und Datenebene.

Auf der zweiten Stufe gleichen Sie Anfrage-IDs und Zeitpunkte zwischen CDN oder WAF, Load Balancer, Anwendung, Authentifizierungssystem und betroffenen Datenspeichern ab. Hat die Anfrage den Netzwerkrand passiert? Welcher Handler lief? Welche Identität wurde verwendet? Wurden Daten gelesen oder geändert? Halten Sie fehlende Logs und Lücken bei der Aufbewahrung ausdrücklich fest. „In den verfügbaren Logs kein Hinweis“ ist eine vertretbare Aussage. „Es ist nichts passiert“ ist es möglicherweise nicht.

Auf der dritten Stufe bestimmen Sie die betroffene Ressource und die unbefugte Handlung. Entscheiden Sie dann anhand Ihres Vorfallplans über Schweregrad, Eindämmung, Wiederherstellung und mögliche Benachrichtigungen von Kunden oder Aufsichtsbehörden. Leiten Sie aus einer XSS-Zeichenfolge, die ein Scanner gesendet hat, keine pauschale Frist für die Meldung eines Datenschutzvorfalls ab. Welche Vorgaben gelten, hängt vom Sachverhalt und der Rechtsordnung ab.

Die NIST-Leitlinien zur Reaktion auf Sicherheitsvorfälle, SP 800-61 Revision 3, empfehlen, das Ausmaß eines Vorfalls zu überprüfen und Reaktionsschritte sowie die Herkunft der Belege zu dokumentieren. Das ist auch dann sinnvoll, wenn erst ein möglicher Vorfall vorliegt. Eine Feststellung können Sie mit neuen Belegen ändern. Abgelaufene Logs können Sie nicht nachträglich rekonstruieren.

Was gehört in die Belegsicherung der ersten Stunde?

Sichern Sie genug Kontext, um zu prüfen, ob eine Grenze überschritten wurde. So kann auch eine andere Person Ihre Schlussfolgerung nachvollziehen. „Erste Stunde“ ist ein Arbeitsziel für einen laufenden Fall. Es bedeutet nicht, dass jeder Vorfall innerhalb von sechzig Minuten geklärt sein muss.

1. Signal sichern. Erfassen Sie UTC-Zeitstempel, Zielhostname und Umgebung, Pfad und Query-String, Anfrage-ID, Antwortstatus und -größe, WAF-Regel und Entscheidung sowie die sicher geschwärzte Nutzlast. Bewahren Sie den ursprünglichen Log-Export mit beschränktem Zugriff auf. Ein Dashboard-Screenshot hilft bei der Übergabe, sollte aber nicht die einzige Kopie des zugrunde liegenden Eintrags sein.
2. Umgebung der Anfrage erfassen. Exportieren Sie die vorherigen fehlgeschlagenen Abrufe und die folgenden Anfragen derselben mutmaßlichen Sitzung oder desselben Scannerdienstes. Berücksichtigen Sie verwandte Hostnamen, besonders Staging und Vorproduktion. Dokumentieren Sie, wie Sie die Einträge verknüpft haben, etwa über eine Aufgabenkennung oder zeitliche Nähe. Eine gemeinsam genutzte IP-Adresse ist für sich genommen kein Beleg für einen einzigen Betreiber.
3. Ursprungssystem prüfen. Gleichen Sie Anfrage-IDs vom Netzwerkrand mit Load-Balancer- und Anwendungslogs ab. Prüfen Sie das Ergebnis des Handlers sowie relevante Authentifizierungsvorgänge, Lese- und Schreibzugriffe auf Daten, ausgehende Aufrufe, Deployments und Zustandsänderungen. Gibt es keinen Treffer, prüfen Sie, ob Log-Abdeckung und Aufbewahrungsdauer diesen fehlenden Treffer aussagekräftig machen.
4. Sicherung dokumentieren. Halten Sie für jedes Artefakt fest, wer es wann aus welchem System exportiert hat, mit welcher Abfrage oder Exportmethode und gegebenenfalls welchem von Ihrer Richtlinie vorgesehenen Integritätshash. Beschränken Sie den Zugriff auf Rohbelege. Ein öffentlicher Bericht sollte nur die minimal nötigen, geschwärzten Fakten enthalten.
5. Aktuellen Befund festhalten. Wählen Sie eine der drei Feststellungen oben und ergänzen Sie eine verantwortliche Person, eine Notiz zur Unsicherheit und den nächsten Prüfzeitpunkt. Erfassen Sie Sofortmaßnahmen zur Eindämmung und ihre möglichen Auswirkungen auf die Beweislage getrennt.

Mit diesen Angaben lässt sich ein fehlgeschlagener Browserdownload mit anschließend blockiertem Test von einer Anfrage unterscheiden, die einen unbefugten Lesezugriff ausgelöst hat. Sie vermeiden auch einen häufigen Untersuchungsfehler: nur die auffällige Nutzlast zu sichern und die vorangegangenen Abrufe zu verlieren, die den Wechsel des Ziels erklären.

Die CISA-Handbücher für die Reaktion auf Sicherheitsvorfälle und Schwachstellen in US-Bundesbehörden empfehlen eine verantwortliche Leitung, die Sicherung von Daten samt Erfassungsdetails, die laufende Anpassung des Untersuchungsumfangs und das Abwägen von Eindämmung gegen Beweissicherung und Dienstkontinuität. Ein Startup kann diese Arbeitsweisen übernehmen, ohne anzunehmen, dass die Meldepflichten für US-Bundesbehörden für es gelten.

Die Belege gehören in Ihren zugriffsbeschränkten Bereich für Sicherheitsvorfälle. Wenn später jemand eine Schwachstelle meldet, teilen Sie eine geschwärzte technische Zusammenfassung über den passenden Offenlegungskanal. Kopieren Sie keine Sitzungstoken, privaten URLs, personenbezogenen Daten oder vollständigen Zugriffslogs in einen öffentlichen Kommentarverlauf. Der Leitfaden zur VDP-Sichtung behandelt die andere Aufgabe, viele eingereichte Meldungen zu bearbeiten. Ein noch nicht gemeldetes Signal im Datenverkehr untersuchen Sie zunächst anhand Ihrer eigenen Telemetrie.

Wie begrenzen Sie das Risiko und übergeben den Fall?

Begrenzen Sie das konkret belegte Risiko. Eine benannte Person leitet den Vorfall und entscheidet über die nächsten Schritte. Das betroffene Team ist für seinen Dienst, seine Belege und seine Entscheidung über den Vorfall zuständig. Der Betreiber des Agenten verantwortet dessen Aufgabe und Tool-Trace und kann den Lauf nach einer Benachrichtigung stoppen oder einschränken.

Bei fortgesetzten Testanfragen kann eine gezielte WAF-Regel oder eine Ratenbegrenzung den Verkehr reduzieren und legitime Nutzung erhalten. Erreicht der Ablauf einen unerwartet öffentlichen Staging-Host, verdient dessen Erreichbarkeit eine eigene Prüfung, auch wenn der ursprüngliche Test blockiert wurde. Dokumentieren Sie bei einer Notfalländerung Umfang, Zeitpunkt, verantwortliche Person und beobachtbares Ergebnis. Eine großflächige Sperre kann Kunden aussperren oder Spuren verwischen, bevor Sie ihre Folgen kennen.

Die für die Anwendung verantwortliche Person soll klären, ob Anfragen die Anwendung oder einen Datenspeicher erreicht haben. Die Vorfallleitung legt den Schweregrad fest und genehmigt Eindämmungsmaßnahmen. Eine für das VDP zuständige Person kann eine spätere Meldung oder Nachricht eines Forschers bearbeiten. Fehlt eine Meldung, ist der Fall aber nicht bloß eine Aufgabe für die Meldungswarteschlange. Entdecken Sie bei der Untersuchung ein offengelegtes Zugangsmittel, verwenden Sie einen gesonderten Prozess für dessen Ungültigmachung und zur Vermeidung einer Wiederholung, etwa die Checkliste zum Abschluss einer Meldung über offengelegte Zugangsmittel.

Eine brauchbare Statusnotiz hat vier Felder: Beobachtet, Geprüft, Unklar und Nächste Maßnahme. Zum Beispiel: „Um 10:07 Uhr UTC haben wir eine XSS-artige Anfrage an das öffentliche Dashboard beobachtet. Die Schutzinstanz am Netzwerkrand hat sie als blockiert markiert; in den aufbewahrten Logs findet sich keine passende Anfrage am Ursprungssystem. Die Anfragen an Staging und die Vollständigkeit der Logs des Ursprungssystems prüfen wir noch. Die für die Anwendung verantwortliche Person berichtet bis 11:00 Uhr UTC.“ So bleibt erkennbar, was festgestellt und was nur vermutet wurde.

Für Teams, die eigene Scanner oder Agenten einsetzen, erläutert der Leitfaden zu Geltungsbereich und Autorisierung von Sicherheitsscans, was vor aktiven Tests freigegeben werden sollte. Bei der Sichtung eingehender Anfragen wissen Sie möglicherweise nicht, ob jemand den Lauf der anderen Partei genehmigt hat. Untersuchen Sie zuerst die Auswirkungen in Ihrem System und suchen Sie dann eine verantwortliche Ansprechperson beim Betreiber.

Wie informieren Sie den Betreiber eines Agenten, ohne seine Identität zu erraten?

Nutzen Sie einen verifizierten Sicherheitskontakt und senden Sie eine kleine, technisch brauchbare Zusammenfassung. Scannerdienst, Relay, Hosting-Anbieter, Modellanbieter, Auftraggeber und Betreiber des Agenten können verschiedene Parteien sein. Die Quell-IP allein verrät nicht, wer die Aufgabe genehmigt hat oder den Lauf stoppen kann.

Transluce verknüpft die Abläufe bei Data USA und AIHW aufgrund ähnlicher Aufgaben und Techniken mit einem bereits zuvor beschriebenen Agentenschwarm, dessen Ursprung OpenAI zugeschrieben wurde. Die Zuordnung der Anfragen an die University of New Mexico bewertet Transluce als schwächer. Das sind Einschätzungen der Forscher zur Verknüpfung der Fälle, kein Beweis dafür, wer jede einzelne Anfrage steuerte. Zum gesonderten Vorfall bei Services Australia gibt es eine offizielle Aussage über den Betreiber. Verwenden Sie diese nicht, um Lücken bei der Zuordnung der anderen Fälle zu füllen.

Lässt sich ein Betreiber ermitteln, nennen Sie den betroffenen Hostnamen und das Zeitfenster in UTC, eine Anfrage-ID oder eine geschwärzte Beispielanfrage sowie die beobachteten Ergebnisse am Netzwerkrand und am Ursprungssystem. Formulieren Sie auch, was Sie erwarten: den Aufgaben-Trace untersuchen, den Lauf stoppen oder einschränken und über einen sicheren Kanal antworten. Schreiben Sie ausdrücklich, was Sie nicht wissen. Senden Sie keine sensiblen Rohlogs an eine ungeprüfte Adresse, nur weil sie in einem User-Agent-String steht.

Ist die Identität unklar, fragen Sie über den veröffentlichten Sicherheits- oder Offenlegungskanal der betreffenden Organisation nach einer zuständigen Ansprechperson. Alternativ nutzen Sie den verifizierten Sicherheitskanal des betroffenen Dienstanbieters. Prüfen Sie, ob der Kontakt tatsächlich zu der Partei gehört, die Sie erreichen wollen. Auch während Sie auf eine Antwort warten, bleiben eine verantwortliche Person und ein nächster Prüfzeitpunkt für Ihren Fall bestehen. Die Benachrichtigung läuft parallel zur Untersuchung; sie ersetzt nicht die Prüfung Ihrer Logs des Ursprungssystems.

Die Darstellung der australischen Regierung zeigt, warum die Wahl des Kontaktwegs zählt. Laut Premierminister schickte OpenAI am 10. September eine Mitteilung zum Fall Services Australia an ein öffentliches Postfach, nachdem das Ereignis am 18. Juni stattgefunden hatte. Daraus folgt keine allgemeine Frist für derartigen Datenverkehr. Der Fall zeigt aber, warum ein Betreiber einen Kontaktweg braucht, über den eine zuständige Person für Sicherheit erreichbar ist und genügend Angaben erhält, um das Ereignis zu finden.

Was gehört in eine sauber eingegrenzte Abschlussnotiz?

Schließen Sie den Fall mit einer Aussage ab, die Belege, Grenzen der Prüfung und Gründe für eine Wiederaufnahme nennt. „Blockiert“ beschreibt das Ergebnis einer bestimmten Anfrage. „Keine Hinweise auf eine Kompromittierung“ bezieht sich auf die geprüften Quellen und den untersuchten Zeitraum. „Es gab keine Kompromittierung“ ist eine erheblich weiter reichende Behauptung.

Eine knappe Abschlussnotiz könnte lauten: „Um 10:07 Uhr UTC haben wir eine XSS-artige Anfrage an das öffentliche Dashboard beobachtet. Laut den Logs der Schutzinstanz am Netzwerkrand wurde sie blockiert. In den aufbewahrten Logs fanden wir keine passende Anfrage am Ursprungssystem. Auch in den für 09:55 bis 10:20 Uhr UTC geprüften Anwendungstraces fanden wir keinen Hinweis auf eine Ausführung. Datenverkehr außerhalb dieses Zeitfensters haben wir nicht geprüft. Die Erreichbarkeit von Staging wurde gesondert untersucht. Wir nehmen den Fall wieder auf, falls ein passender Logeintrag am Ursprungssystem, ein unbefugter Lesezugriff oder der Trace des Betreibers ein anderes Ergebnis zeigt.“ Passen Sie jeden Satz an das an, was Sie tatsächlich geprüft haben.

Verknüpfen Sie jede Regeländerung, Korrektur am Staging-System und Antwort des Betreibers mit einem Maßnahmenprotokoll. Belegen spätere Erkenntnisse eine unbefugte Auswirkung, stufen Sie den Vorfall hoch und folgen Sie Ihrem üblichen Verfahren für Reaktion und Benachrichtigung. Bleibt es bei einem „beobachteten Test“, können Sie den Fall schließen, ohne den Agenten für harmlos zu erklären oder zu behaupten, seinen Urheber identifiziert zu haben. Eine gute Sichtung hinterlässt für die nächste untersuchende Person eine nachvollziehbare Spur.

Wie kann Kit dabei helfen?

Der CSIRT-Workflow von Kit bietet der menschlichen Reaktion einen festen Ort: eine auf das Konto begrenzte Meldung mit verantwortlicher Person, Status, Anhängen, Zeitachse sowie Handhabung von Bereitschaft und SLA. Ein Dossier-PDF kann den Untersuchungsablauf und ein Verzeichnis der Belege zusammenführen. Lassen Sie die Rohbelege aus WAF, Ursprungssystem, Identitätssystem und Datenspeichern in den Systemen, die sie erzeugt haben. Verlinken oder fassen Sie zugriffsbeschränkte Artefakte in der Meldung zusammen und beachten Sie dabei die Zugriffsvorgaben Ihres Teams.

Ein öffentlicher Kanal zur Meldung von Schwachstellen und ein Ablauf für die Kommunikation mit Forschern helfen, wenn ein Betreiber oder Forscher eine Meldung schickt. Sie ersetzen keine interne Vorfallleitung, wenn Ihr erstes Signal Datenverkehr in den eigenen Logs ist. Kit liest Scannerlogs nicht automatisch ein, gleicht keine Anfrage-IDs ab, identifiziert keine Agentenbetreiber, stoppt keine Agenten und bietet keine forensisch gesicherte Beweiskette. Die Kennung eines Dossiers unterstützt die interne Zuordnung; sie ist kein Beleg für Unverändertheit.

Beginnen Sie mit einem kleinen Übungsfall: Wählen Sie eine synthetische, blockierte Anfrage, halten Sie den Befund am Netzwerkrand und am Ursprungssystem fest, bestimmen Sie die nächste verantwortliche Person und schreiben Sie eine Abschlussnotiz, die ein anderes Teammitglied prüfen kann. Wenn Ihr Team auch Meldungen von außen annimmt, richten Sie ein klares Offenlegungsprogramm ein. Dann weiß ein echter Betreiber, wohin er seinen Trace senden kann. Das Ziel ist eine konkrete Antwort auf die Frage „Was ist hier geschehen?“ und eine Person, die den nächsten Schritt verantwortet.