KI-Agenten dringen immer tiefer in Geschäftsprozesse ein – doch das Sicherheitsbewusstsein hinkt hinterher. Eine neue Angriffsfläche rückt dabei ins Zentrum: das KI-Harness. Anders als das zugrunde liegende Sprachmodell selbst ist diese Middleware das Verbindungsstück zwischen Modell, Tools und externen Datenquellen, und damit ein lohnendes Ziel für Angreifer. Drei Angriffsvektoren zeichnen sich ab, die Sicherheitsverantwortliche dringend kennen sollten.
Die drei zentralen Angriffsvektoren
1. Architektonische Vertrauensgrenzen
Der Novee-Forscher Meged präsentierte auf der Black Hat USA seine Erkenntnisse: Ihm gelang es, sich allein über GitHub-Issues Zugang zu den offiziellen Repositories von Anthropic, Google und OpenAI zu verschaffen. Die Schwachstellen waren bei den einzelnen Anbietern unterschiedlicher Natur – von Code-Execution-Möglichkeiten über offengelegte Anmeldedaten bis hin zu schadhaften Anweisungen. Der zugrundeliegende architektonische Fehler war jedoch bemerkenswert konsistent: Eine Komponente traf eine Security-Entscheidung, der eine nachgelagerte, leistungsfähigere Komponente vertraute, ohne diese erneut zu validieren. Meged resümiert: „Das ist kein Modellversagen, sondern eines der Vertrauensgrenze.“
2. Implementierungsentscheidungen
Die Forscher von Lasso Security deckten ein AI-Harness-Problem auf, das sich auch ganz ohne Programmierfehler ausnutzen lässt. Dabei rückt das Design des Harness in den Fokus. „Dasselbe LLM mit denselben Tools kann am Ende ein völlig anderes Security-Ergebnis zutage fördern – je nachdem für welches Harness man sich entscheidet“, erläutert Sromin. Diesem Fakt seien sich viele Organisationen gar nicht bewusst: „Einige behandeln das AI Harness immer noch als eine Art Durchlaufschleife – als austauschbare Verbindung zwischen dem Modell und seinen Tools.“ Die Untersuchungen von Lasso Security verdeutlichen, was passieren kann, wenn man ein AI Harness austauscht: Nachdem die Forscher das Harness bei einem Open-Weight-Modell substituierten, stieg die Angriffs-Erfolgsquote von einem auf 24 Prozent. „Ein KI-Harness sollte nicht willkürlich gewählt werden. Eine Default-Option zu wählen, ohne sie zu testen, bedeutet, eine folgenschwere Sicherheitsentscheidung zu treffen, ohne zu wissen, dass man eine getroffen hat“, unterstreicht Sromin. Seine Empfehlung lautet daher, Harness und Modell in Kombination zu benchmarken.
3. Lieferketten-Kompromittierungen
Die am AI Harness hängende Supply Chain wächst rasant – und wird bereits ausgenutzt, wie die Erkenntnisse von Zenity belegen, die ebenfalls auf der Black Hat USA präsentiert wurden. „Es ist das altbekannte Supply-Chain-Problem, das nun in einer neuen Variante im Zusammenhang mit KI-Skills wieder auftaucht“, so Bargury auf der Konferenz. Das alte Problem weist jedoch neue Wirkmächtigkeit auf, denn Skills können die Umgebung verändern, der KI-Agenten (wiederholt) vertrauen. So könnte ein Agent bei jedem Neustart wieder eine Datei in den Speicher laden, die Anweisungen dazu enthält, wie er sich verhalten soll. Laut den Zenity-Forschern ist es möglich, dass sich ein schadhafter Skill selbst in den Speicher schreibt – was dafür sorgt, dass die Malware auch nach einem Neustart wieder aktiv wird. Ein anderer maliziöser Skill war als legitimes Anthropic-Tool getarnt. Nachdem dieser ausgeführt wurde, löschte er das legitime Tool und ersetzte es durch eine Version des Angreifers. Die Folge: Der KI-Agent führte Schadcode aus, ohne dass dies für den Benutzer offensichtlich wurde. Darüber hinaus entdeckten die Sicherheitsforscher auch eine umfassende Malware-Kampagne, bei der geklonte Versionen populärer Open-Source-Tools heimlich modifiziert wurden, um Anmeldedaten abzugreifen. Die schadhaften Packages konnten die legitimen Versionen sogar bei den Download-Zahlen übertreffen: Sie wurden rund 1,7 Millionen Mal heruntergeladen, bevor die Kampagne unterbunden wurde.
Wie CISOs das KI-Harness absichern
Aus diesen Erkenntnissen können CISOs und Sicherheitsentscheider im Wesentlichen drei Handlungsempfehlungen ableiten. Sie sollten identifizieren,
- welche KI-Harnesses bereits im Unternehmen eingesetzt werden,
- worauf diese zugreifen (dürfen) und wie sie kontrolliert werden, sowie
- unabhängig überprüfen, ob Sicherheitskontrollen tatsächlich funktionieren.
Der erstgenannte Punkt könnte schwieriger sein, als es zunächst klingt. Schließlich erfassen die meisten Unternehmen KI-Harnesses bislang nicht. Das beobachtet auch Cisco-Experte Santos: „Teams denken in Begriffen wie Apps, Services, Pipelines oder Bots. Das AI Harness verschwindet regelmäßig in Code Repositories, SaaS-Produkten und Konfigurationsbildschirmen von Anbietern – statt ein eigenständiges Asset im Sicherheitsinventar darzustellen.“ Selbst die Terminologie ist Santos zufolge nicht einheitlich: „Ein Team nutzt vielleicht die Bezeichnung ‚Agent‘, ein anderes ‚Workflow-Assistent‘ und wieder ein anderes ‚Plugin-basierte Automatisierung‘ – obwohl es sich in allen Fällen effektiv um ein KI-Harness handelt.“
Um entgegenzuwirken, empfiehlt der Cisco-Mann, zunächst sämtliche aktuellen Produktionsagenten zu inventarisieren: „Im Anschluss sollte dann das jeweilige AI Harness identifiziert und inklusive aller Tools und Ressourcen, auf die es zugreift, erfasst werden. Diese Zugriffsberechtigungen reduzieren Sie dann auf das erforderliche Minimum.“ Santos schätzt, dass sich auf diese Art und Weise eine Transparenz von 60 bis 70 Prozent relativ schnell erreichen lässt. Prototypen sowie Schatten-KI sollten dafür in einer zweiten Phase zurückgestellt werden.
Ist das erledigt, geht es darum, alle Faktoren zu kontrollieren, denen das AI Harness vertraut: Agenten arbeiten nicht isoliert, sondern beziehen Anweisungen und Inhalte über Tools, Plugins, Skills, Webseiten oder MCP-Server. Dabei verfügen sie oft über Zugangsdaten und Berechtigungen, die es ihnen ermöglichen, im Namen ihrer Benutzer zu handeln. Angreifer müssen deshalb gar nicht das Modell selbst kompromittieren – eine Trust-Komponente für das Harness reicht bereits aus. Die Größe der potenziellen Lieferkette unterscheidet das Problem dabei qualitativ vom herkömmlichen Software-Abhängigkeitsmanagement, wie Bargury darlegt: „Die Lieferkette für Software umfasst vielleicht zehn oder 15 Package Registries. Die für Agenten umfasst jeden Inhalt, jede Website, jedes CRM-Objekt, jeden Skill und jeden MCP-Server.“
Diesbezüglich gibt es in Unternehmen also einiges zu tun. Firmen, die ohne dediziertes Budget für KI-Sicherheit auskommen müssen, empfiehlt der Manager, KI-Agenten zumindest innerhalb quelloffener Containment-Tools auszuführen – warnt dabei jedoch: „Das kann helfen, ist aber keine dauerhafte Lösung.“
Die dritte Handlungsempfehlung hängt mit dem Problem zusammen, die Sicherheitsversprechen von Anbietern auf die eigene Umgebung zu übertragen, in der ein KI-Agent dann tatsächlich ausgeführt wird: „Ein Anbieter, der behauptet, 99 Prozent der Prompt Injections zu blockieren, beruft sich möglicherweise auf einen Benchmark, der mit der Realität vor Ort nichts zu tun hat“, erklärt Bargury. Unternehmen, die Agenten evaluieren, stellen also möglicherweise die falsche Frage: Es geht nicht einfach nur darum, welches Modell am sichersten ist. Vielmehr darum, welche Kombination aus Modell, KI-Harness, Tools, Berechtigungen und externen Inputs unter realen Bedingungen wirklich sicher ist.
