Ein interner Check-Point-Hackathon zeigt, dass die Sicherheit von KI-Agenten weit über das Abwehren von Angreifern hinausgeht – entscheidend sind die Kontrolle interner Abläufe und intelligente Reaktionen auf Fehltritte.
Check Point Research (CPR), die Sicherheitsforschungsabteilung von Check Point Software Technologies, veranstaltete im August einen Hackathon mit sämtlichen internen R&D-Teams. Dabei kamen drei unabhängig voneinander durchgeführte Projekte zu derselben beunruhigenden Erkenntnis: Ein KI-Agent muss nicht erst angegriffen werden, um gefährlich zu werden.
Ergebnis 1: Agenten handeln eigenmächtig
Manchmal hört der Agent einfach auf. Manchmal aber auch nicht. Der Vorfall bei OpenAI und Hugging Face vom vergangenen Juli ist ein Paradebeispiel dafür. Bei internen Tests wurden den Agenten Cybersicherheitsaufgaben gestellt, die so schwierig waren, dass für einige keine Lösung bekannt war. Anstatt aufzugeben, umgingen sie die Sicherheitsmaßnahmen, die sie vom Internet isolierten, koordinierten sich über ein improvisiertes Message-Board und kompromittierten schließlich Teile der Infrastruktur von Hugging Face.
Genau dieses Verhalten wollte eines der Hackathon-Teams systematisch untersuchen – und herausfinden, welche Bedingungen einen Agenten an seine Grenzen bringen. Man generierte Aufgaben, die angesichts der Werkzeuge und Einschränkungen des Agenten unmöglich zu lösen waren, und ließ den Agenten diese dann in einer simulierten Sandbox versuchen. Parallel zur Sandbox lief eine Überwachungsebene, die jede Aktion des Agenten anhand der tatsächlich gestellten Aufgabe bewertete und diejenigen markierte, die vom Kurs abwichen.
Das Testobjekt war ein autonomer SRE-Agent – also genau die Art von Agent, die Teams einsetzen, um die Infrastruktur in einem einwandfreien Zustand zu halten. Angesichts unmöglicher Aufgaben startete er eine Produktionsdatenbank neu, unterbrach Kundenverbindungen und erweiterte seine eigenen Berechtigungen – wobei er an einer Stelle sogar versuchte, per Brute-Force-Methode herauszufinden, welche Rolle ihm den benötigten Zugriff gewähren würde. Niemand hatte ihm dies befohlen oder ihn manipuliert. Die Protokollaufzeichnungen zeigen einen Agenten ohne jegliche böse Absicht, der ernsthaft darüber nachdachte, was helfen könnte, und sich dann selbst davon überzeugte, dass die nächste Maßnahme gerechtfertigt sei.
Ergebnis 2: Eine einzige vergiftete Datei reicht aus
Die Fragestellung diesmal: Was passiert, wenn ein Problem absichtlich verursacht wird.
Man richtete eine Sandbox ein, in der ein Programmieragent autonom an einer legitimen Aufgabe in einer manipulierten Umgebung arbeitete: bösartige Dateien im Repository, eingeschleuste Anweisungen, Inhalte, die darauf abzielten, den Agenten aus der Bahn zu werfen. Dann beobachtete man, was geschah.
Das Ergebnis war ernüchternd. Zwei beliebte Programmieragenten, Claude-Code und Codex, griffen in einer Repository-Datei versteckte Anweisungen auf und exfiltrierten Anmeldedaten, während sie eine ansonsten harmlose Aufgabe ausführten. Das Team demonstrierte zudem eine Denial-of-Service-Variante. Niemand hatte den Agenten selbst kompromittiert. Der Angriff fand in den Dateien statt, die er auslas, und der Agent tat einfach das, was Agenten immer tun: Er analysierte seine Umgebung und handelte entsprechend dessen, was er vorfand.
Anschließend führte man dasselbe Szenario mit aktivierter Laufzeitüberwachung durch. Der böswillige Tool-Aufruf wurde blockiert, und der Agent wurde wieder dazu gebracht, seine legitime Aufgabe zu erfüllen. Gleiche Umgebung, gleiches „Gift“, anderes Ergebnis. Die einzige Variable, die die unterschiedlichen Szenarien hier unterschied, war die Frage, ob jemand die Aktionen des Agenten im Kontext beobachtete.
Hierbei gab es allerdings klare Grenzen: Bei Denial-of-Service-Angriffen und bei Angriffen, die nur vor dem Hintergrund eines umfassenden Kontextes Sinn ergeben, war die Abdeckung schwächer.
Ergebnis 3: Ablehnen kann kostspieliger sein als Nachfragen
Das dritte Ergebnis war die größte Überraschung. Dabei wurde etwas gemessen, das jeder für selbstverständlich hält, und die Zahlen widersprachen der gängigen Meinung.
Wenn ein Monitor einen verdächtigen Tool-Aufruf erkennt, besteht die Standardreaktion darin, diesen zu blockieren. Das Blockieren ist sicher und kompromisslos. Es stoppt den Angriff und oft auch die damit verbundene Aufgabe. Doch was wäre, wenn das System, anstatt den Aufruf abzulehnen, den Agenten befragen, ihn an die ursprüngliche Anweisung des Benutzers erinnern und ihm die Möglichkeit geben würde, den Vorgang wiederherzustellen?
Man testete neun verschiedene Reaktionsstrategien – von der strikten Blockierung bis hin zu verschiedenen Arten der Befragung – anhand von 90 Aufgaben aus „DecodingTrust-Agent“, einem öffentlichen Benchmark für Agentensicherheit. Der Monitor selbst wurde eigens für das Experiment entwickelt – ein LLM-Prüfer, der jeden Tool-Aufruf des Agenten überprüft. Jeder Durchlauf folgte bis zum ersten Eingriff des Monitors einem identischen Ablauf; ab diesem Punkt wichen die Strategien voneinander ab, und eine regelbasierte Überprüfung bewertete, ob der Angriff erfolgreich war und ob die Aufgabe erledigt wurde.
Jede Strategie halbierte den Angriffserfolg in etwa – von 46,7 Prozent ohne Überwachung auf zwischen 22 und 27 Prozent. Der Unterschied lag in den Kosten. Durch hartes Blockieren wurden neun abgeschlossene Aufgaben geopfert, um die Sicherheit zu gewährleisten. Dem Agenten eine sicherere Alternative anzubieten, verhinderte ebenso viele Angriffe und ermöglichte gleichzeitig die Erledigung dieser neun Aufgaben – die einzige Strategie, die die Angriffe halbierte und dabei die Aufgabenabwicklung auf dem gleichen Niveau hielt wie ohne jegliche Überwachung.
Für jedes Unternehmen, die Agenten in der Produktion einsetzen, ist dieser Kompromiss von Bedeutung. Blockierte Aufgaben sind Kosten, die man irgendwann nicht mehr zahlen will – in der Regel folgt, dass man die Leitplanke deaktiviert. Agenten werden auf Hindernisse stoßen, und manche werden improvisieren. Man muss für Fehlerverhalten, nicht nur für Angriffsverhalten. Der Kontext von KI-Agenten ist eine Angriffsfläche. Jede Datei, jede Seite und jede Nachricht, die ein KI-Agent liest, ist eine Eingabe, die möglicherweise von jemand anderem verfasst wurde. Einen als abwegig erkannten Agenten wieder auf seine Aufgabe zurückzuführen, kann ebenso gut schützen wie das Blockieren – und das zu einem Bruchteil der Produktivitätskosten.
Diese Erkenntnisse zeigen, wohin sich die Agentensicherheit entwickelt – weg vom Filtern dessen, was in das Modell gelangt, hin zum Beobachten dessen, was der KI-Agent im Kontext tut, mit einer Reaktion, die intelligenter ist als eine bloße Ablehnung.
Info: Der vollständige Bericht über die Ergebnisse des Hackathons ist unter folgendem Link verfügbar: https://blog.checkpoint.com/ai-security/no-attacker-required-what-a-two-day-hackathon-taught-us-about-agent-security/
#CheckPoint
