davon überzeugte, dass die nächste Maßnahme gerechtfertigt sei. Eine vergiftete Datei genügt 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. Ablehnen oder besser 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 alle 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 bewerten. Der Kontext von Agenten ist eine Angriffsfläche. Jede Datei, jede Seite und jede Nachricht, die ein 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 Agent im Kontext tut, mit einer Reaktion, die intelligenter ist als eine bloße Ablehnung. Check Point Research stellt Check Point Software-Kunden und der gesamten Geheimdienst-Community führende Erkenntnisse über Cyber-Bedrohungen zur Verfügung. Das Forschungsteam sammelt und analysiert globale Cyber-Angriffsdaten, die in der ThreatCloud gespeichert sind, um Hacker in Schach zu halten und gleichzeitig sicherzustellen, dass alle Check Point-Produkte mit den neuesten Schutzmaßnahmen aktualisiert werden. Das Forschungsteam besteht aus über 100 Analysten und Forschern, die mit anderen Sicherheitsanbietern, Strafverfolgungsbehörden und verschiedenen CERTs zusammenarbeiten. www.checkpoint.com Vorfall ohne Verbrecher Anstatt aufzugeben, umgingen die KI-Agenten die Sicherheitsmaßnahmen, die sie vom Internet isolierten
RkJQdWJsaXNoZXIy MjE2Mzk=