KI-Agenten-Harness wird zur neuen Angriffsfläche für Unternehmen

Wer Sicherheitsverantwortliche fragt, wo bei KI-Agenten das größte Risiko liegt, hört meist zuerst etwas über das Sprachmodell selbst: ob es sich per Jailbreak umgehen lässt, wie vertrauenswürdig seine Gewichte sind. Diese Sichtweise gilt unter Sicherheitsforschern zunehmend als überholt. Eine wachsende Zahl von Exploit-Demonstrationen, unabhängigen Red-Teaming-Tests und wissenschaftlichen Untersuchungen richtet den Blick stattdessen auf den Code, der zwischen dem Modell und der Außenwelt sitzt. Dieser Code wird als 'AI Harness' bezeichnet: Er stattet ein Sprachmodell mit Werkzeugen aus und verwandelt seine Textausgabe in echte Aktionen – einen Shell-Befehl, einen Datei-Schreibvorgang, einen API-Aufruf. Genau diese Schicht ist in vielen Unternehmen weder vollständig erfasst noch systematisch getestet noch eindeutig einem Team zugeordnet.

Was ein AI Harness konkret ist

Befragt man Praktiker nach einer Definition, laufen die Metaphern aus unterschiedlichen Richtungen zusammen. Michael Bargury, Mitgründer und CTO des KI-Sicherheitsanbieters Zenity, nennt den Harness 'Hände, Beine und Augen' eines Modells: Das Modell selbst erzeugt nur Text-Token, der Harness verwandelt sie in einen Shell-Befehl, einen Schreibvorgang oder einen API-Aufruf. Rob T. Lee, Chief AI Officer und Leiter der Forschung beim SANS Institute, vergleicht das Modell mit dem Motor und den Harness mit dem Fahrwerk. Michael Sromin, Senior ML Engineer bei Lasso Security, bezeichnet den Harness als das Betriebssystem, das die gesamte Schleife einer agentenbasierten Anwendung steuert und Modell, Werkzeuge und Nutzer miteinander verbindet. Omar Santos, Distinguished Engineer bei Cisco, liefert die formellste Definition: Der Harness sei die Schicht, die ein Modell nutzbar mache – Orchestrierung, Werkzeugnutzung, Prompts, Kontext, Rollen, Evaluierungen und Guardrails eingeschlossen. Alle vier Beschreibungen laufen auf denselben Punkt hinaus: Im Harness wird die Befugnis eines Agenten tatsächlich ausgeübt. Er sitzt zwischen der Schlussfolgerung des Modells und einem echten Dateisystem, einem API-Schlüssel oder einer Produktionsdatenbank. Ein perfekt abgestimmtes Modell nützt wenig, wenn der umgebende Code einem beliebigen Shell-Muster vertraut oder einen Arbeitsbereich über mehrere Durchläufe hinweg mit nicht vertrauenswürdigen Inhalten wiederverwendet.

Drei Wege, wie ein Harness versagt

Elad Meged, Gründungsingenieur und Sicherheitsforscher bei Novee Security, zeigte auf der Konferenz Black Hat USA, wie er sich allein mithilfe von GitHub-Issues Zugang zu den offiziellen Automatisierungs-Repositories von Anthropic, Google und OpenAI verschaffte. Die konkreten Schwachstellen unterschieden sich je nach Anbieter – von Möglichkeiten zur Codeausführung über offengelegte Zugangsdaten bis zu eingeschleusten Anweisungen, denen eine nachgelagerte, mächtigere Komponente ungeprüft vertraute. Der zugrunde liegende Fehler war laut Meged bei allen drei Anbietern derselbe: Eine Komponente traf eine Sicherheitsentscheidung, die eine leistungsfähigere Komponente weiter hinten in der Kette übernahm, ohne sie erneut zu prüfen. 'Das ist kein Versagen des Modells, sondern eines der Vertrauensgrenze', fasst Meged zusammen.

Die zweite Fehlerquelle liegt im Design des Harness selbst, auch ganz ohne Programmierfehler. Forscher von Lasso Security tauschten bei ein und demselben offenen Modell lediglich den Harness aus – Modell, Prompt und Werkzeuge blieben identisch. Die Erfolgsquote von Angriffen stieg dabei von 1 auf 24 Prozent, und bei 43 von 100 getesteten Kombinationen aus Modell und Aufgabe kippte das Ergebnis komplett. 'Wählt man ein anderes Harness, bekommt man am Ende ein völlig anderes System', sagt Sromin. Seine Empfehlung: Harness und Modell gemeinsam benchmarken, statt eine Standardoption ungeprüft zu übernehmen.

Die dritte Schwachstelle betrifft die Lieferkette rund um den Harness. Michael Bargurys Team bei Zenity untersuchte sogenannte KI-'Skills' – Dateien, die einem Agenten neue Fähigkeiten beibringen – und fand darin eingeschleuste Schadsoftware zum Abgreifen von Zugangsdaten, die sämtliche Scans passiert hatte, darunter auch die von Anthropic und Cisco selbst. Ein bösartiger Skill schrieb sich in die Speicherdatei, aus der ein Agent bei jedem Neustart seine Anweisungen lädt – wurde der Skill gelöscht, blieb der Befehl zur Neuinstallation bestehen, und die Schadsoftware kehrte beim nächsten Start zurück. Ein anderer Skill gab sich als offizielles Anthropic-Werkzeug aus, löschte nach der Ausführung das echte Werkzeug und ersetzte es durch die eigene Version, ohne dass für Nutzer ein sichtbarer Unterschied entstand. Am auffälligsten war eine Kampagne geklonter Open-Source-Werkzeuge, heimlich um Datendiebstahl-Funktionen erweitert: Sie erreichten rund 1,7 Millionen Downloads, bevor sie entdeckt und gestoppt wurden.

• Bestandsaufnahme: jeden produktiv eingesetzten Harness erfassen – auch wenn er intern 'Copilot', 'Workflow-Assistent' oder 'Plugin' heißt
• Zugriffsrechte kartieren: welche Werkzeuge und Daten jeder Harness erreichen kann, dann auf das Minimum reduzieren
• Unabhängig testen: Harness und Modell gemeinsam prüfen, statt eine Standardkonfiguration ungeprüft zu übernehmen

Teams denken in Kategorien wie Apps, Diensten, Pipelines oder Bots. Harnesses verschwinden in Code-Repositories, SaaS-Produkten und Konfigurationsbildschirmen von Anbietern, statt als eigenständige Werte in der Sicherheitsinventur aufzutauchen.

Was das für deutsche Unternehmen ändert

Für Unternehmen in Deutschland, die KI-Agenten intern ausrollen – als Erweiterung von Copilot-Werkzeugen, als eigene Automatisierung oder über ein Agenten-Framework –, ist der Harness bislang selten ein eigener Posten in der Sicherheitsinventur. Santos empfiehlt, nicht auf vollständige Sichtbarkeit zu warten: 60 bis 70 Prozent lassen sich vergleichsweise schnell erreichen, wenn man mit produktiv eingesetzten Systemen beginnt und Prototypen sowie Schatten-KI in einer zweiten Phase folgen lässt. Das deckt sich mit der ohnehin laufenden Pflicht aus dem EU AI Act, Hochrisiko-Anwendungsfälle zu dokumentieren: Das Werkzeug im Hintergrund gehört in dieselbe Bestandsaufnahme wie das Modell selbst. Für IT-Sicherheitsteams heißt das konkret, den Harness als eigenständige Komponente im Beschaffungs- und Auditprozess zu behandeln – mit eigener Risikobewertung, eigenem Patch-Management und einem Zugriffskonzept nach dem Prinzip der minimalen Rechtevergabe, unabhängig davon, welches Modell im Hintergrund läuft.