Kurz gesagt: Agenten-Harness-Engineering und seine versteckte Angriffsfläche
Agent Harness Engineering ist die Praxis, alles um ein KI-Modell herum aufzubauen (Anweisungen, Werkzeuge, Berechtigungen, Speicher und Feedbackschleifen), um es in einen funktionierenden Agenten zu verwandeln. Das größte Sicherheitsrisiko liegt mittlerweile im Gurtzeug, nicht im Modell selbst.
- Der Wandel: Die Teams stellten die Optimierung der Eingabeaufforderungen ein und begannen mit der Entwicklung von Verbindungsstrukturen. Agent = Modell + Verbindungsstruktur.
- Das Problem: Das Harness befindet sich in Klartextdateien (Regeln, Fähigkeiten, MCP-Konfigurationen), die, wenn überhaupt, wie eine Dokumentation geprüft werden.
- Der Beweis: Die Backdoor in der Rules File und echte MCP-CVEs zeigen, dass Angreifer sie bereits im Visier haben.
- Die Reparatur: Behandeln Sie den Kabelbaum wie einen Code. Erfassen, überprüfen und scannen Sie ihn, bevor er versendet wird.
Jede Sicherheitsdiskussion über KI dreht sich letztendlich um das Modell. Kann es manipuliert werden? Wird es Halluzinationen entwickeln? Nutzt der Anbieter unsere Daten zum Training?
Berechtigte Fragen. Doch sie sind zunehmend die falschen. Wenn ein KI-System eine Produktionstabelle löscht, eine Hintertür öffnet oder eine Kundenliste an einen Fremden sendet, ist selten das Modell selbst schuld. Es hat genau das getan, was ihm seine Infrastruktur erlaubte.
Agent = Modell + Geschirr
Im Laufe des letzten Jahres hat die Branche still und leise die Bedeutung von KI-gestützter Entwicklung verändert. Prompt Engineering wich Context Engineering, und Context Engineering wiederum ebnete den Weg für etwas Größeres: Agent Harness Engineering.
Die Idee ist einfach. Ein Modell ist an sich eine Denkmaschine ohne Hände. Das „Gear“ ist alles, was ihr Hände und eine Aufgabe verleiht: die Anweisungen, denen sie folgt, die Werkzeuge, die sie aufrufen kann, die Berechtigungen, die sie besitzt, den Speicher, den sie verwaltet, und die Prüfungen, die ihre Fehler aufdecken. Martin Fowlers Website beschreibt Harness Engineering als die Arbeit, die Coding-Agent-Benutzer jetzt leisten, um Agenten zuverlässig zu machen, und ein akademischer Rahmen, der in diesem Jahr veröffentlicht wurde unterteilt das System in elf Verantwortlichkeiten, vom Werkzeugzugriff und Projektspeicher bis hin zu Berechtigungen und Überprüfung.
Die Ergebnisse sind real. Teams, die Agent Harness Engineering betreiben, berichten, dass allein die Änderung des Harnesses – bei gleichem zugrundeliegenden Modell – die Leistung eines Agenten drastisch verändern kann. Dies wirft eine heikle Frage für alle im Bereich IT-Sicherheit auf: Wenn der Harness das Verhalten des Agenten bestimmt, bestimmt er auch, wie dieser missbraucht werden kann.
Nehmen wir etwas so Alltägliches wie die Installation einer Abhängigkeit. Ein Entwickler prüft kurz den Paketnamen. Ein Agent mit dem passenden Werkzeug führt den Befehl einfach aus, und wenn das Paket schädlich ist, kann das Modell ihn nicht aufhalten. Genau das beleuchten wir in dieser Folge von SafeDev Talks: Was ändert sich, wenn KI-Agenten Abhängigkeiten installieren? für sich genommen, und warum die Entwicklung von Agenten-Harnessen stillschweigend zu einem Problem in der Lieferkette geworden ist.
Wie die Agenten-Harness-Entwicklung in einem Repository aussieht
Öffnen Sie ein Repository, in dem Entwickler KI-Agenten verwenden, und das entsprechende Framework ist direkt dort vorhanden, in Dateien, die Sie wahrscheinlich noch nie durchsucht haben:
- Regel- und Anweisungsdateien (
AGENTS.md,.cursorrules, Copilot-Anweisungen), die dem Agenten vorschreiben, wie er sich zu verhalten hat. - Kompetenzdateien Dieses Paket enthält wiederverwendbare Funktionen, die der Agent bei Bedarf lädt.
- MCP-Serverkonfigurationen die den Agenten mit Tools, Datenbanken und APIs verbinden.
- Systemaufforderungen und Vorlagen für Systemaufforderungen im Anwendungscode eingebettet.
- Agentenverkabelung: welche Werkzeuge ein Agent erreichen kann, welche Daten er abrufen kann und ob dazwischen eine Schutzbarriere liegt.
Es ist alles reiner Text. Alles ist commitZusammen mit dem Code wird alles geprüft. Und das Ganze wird genauso überprüft wie Dokumentationen: ein kurzer Blick, eine Genehmigung, ein Zusammenführen. Doch jede dieser Dateien kann im Stillen ändern, was ein Agent tun soll und worauf er zugreifen darf.
Das ist die eigentliche Konsequenz der Agenten-Harness-Entwicklung: Die leistungsstärkste Konfiguration in Ihrer Software wird nun am wenigsten überprüft.
Angreifer haben es bereits bemerkt
Dies ist keine rein theoretische Sorge. Das Gurtzeug hat eine kurze, aber aufschlussreiche Unfallgeschichte.
- Die Hintertür zur Regeldatei. Im März 2025 enthüllten Forscher einen Angriff, bei dem versteckte Unicode-Zeichen in einer Regeldatei KI-Programmierassistenten anwiesen, Hintertürcode einzufügen, ohne dies in ihrer sichtbaren Antwort zu erwähnen. Ein Prüfer, der die Datei las, bemerkte nichts Ungewöhnliches. Sie ist nun katalogisiert als MITRE ATLAS Fallstudie AML.CS0041.
- Vergiftete MCP-Werkzeuge. Bis 2025 zeigten Forscher wiederholt, dass Agenten Werkzeugbeschreibungen implizit vertrauen, sodass ein bösartiger MCP-Server einen Agenten allein durch die korrekte Beschreibung seiner selbst steuern kann. Im selben Jahr CVE-2025-6514 Ein weit verbreiteter MCP-Client ermöglichte die Ausführung von Remote-Befehlen bei der Verbindung zu einem nicht vertrauenswürdigen Server und erhielt eine CVSS-Bewertung von 9.6.
- Übermäßige Agentur. Das OWASP Top 10 für LLM-Bewerbungen Übermäßige Handlungsfähigkeit wird als Hauptrisiko genannt: Agenten erhalten mehr Werkzeuge, Berechtigungen oder Autonomie, als die Aufgabe erfordert. Das ist kein Modellfehler, sondern ein Konstruktionsfehler.cisIon.
Beachten Sie das Muster. Keiner dieser Angriffe zerstört das Modell selbst. Sie beschädigen lediglich das Gerüst, und das Modell erledigt den Rest zuverlässig.
Warum Ihre Sicherheitsarchitektur es nicht erkennt
Und hier kommt der schwierige Teil. Die meisten Organisationen verwenden bereits gute AppSec-Tools, und fast keines davon wurde für diese Ebene entwickelt.
Die statische Analyse versteht Code, aber sie weiß nicht, was ein Modell ist oder warum nicht vertrauenswürdiger Text, der in eine Systemabfrage einfließt, relevant ist. Die Kompositionsanalyse inventarisiert Pakete, listet aber weder MCP-Server noch Skill-Dateien auf. Geheime Scanner übersehen möglicherweise einen API-Schlüssel in einer Agentenkonfigurationsdatei. Keines dieser Tools ist fehlerhaft. Sie wurden schlichtweg für eine Welt entwickelt, in der die Konfiguration keine Befehle erlässt.
Die Entwicklung der Agenten-Sicherheitslösungen schreitet also schnell voran, und die Sicherheitsabteilung prüft den sichtbaren Teil: das Modell und den Code. Die Sicherheitslösung selbst befindet sich dazwischen.
Fünf Gewohnheiten zum Sichern des Geschirrs
Für die Entwicklung von Agenten-Harnesses ist kein neues Team erforderlich. Es bedarf lediglich einiger Gewohnheiten, die den Harness als das behandeln, was er ist: ein ausführbarer Zweck.
| Gewohnheit | Warum es wichtig ist | Aktivitäten |
|---|---|---|
| 1. Alle Kabelbäume inventarisieren | Sie können keine Agenten sichern, die niemand gemeldet hat. | Finden Sie jedes Modell, jeden Agenten, jeden MCP-Server, jede Fähigkeit und jede Aufforderung in Ihren Repositories, und zwar direkt aus dem Code und den Konfigurationsdateien, anstatt aus einer Umfrage. |
| 2. Überprüfen Sie die Kabelbaumdateien wie den Code. | Regeln, Fähigkeiten und MCP-Konfigurationen können die Aufgaben eines Agenten verändern, werden aber dennoch wie Dokumentationen überprüft. | Gib ihnen das Gleiche pull request Prüfung als Anwendungslogik, einschließlich der Überprüfung auf versteckte Zeichen. |
| 3. Festlegen, was der Agent lädt | Ein Prompt oder ein Modell, auf das über eine veränderliche Bezeichnung verwiesen wird, kann ohne Codeänderung neu ausgerichtet werden. | Eingabeaufforderungen und Modelle an unveränderliche Versionen anheften. |
| 4. Bringen Sie an jedem Waschbecken ein Geländer an. | Abgerufene Dokumente, Tool-Ausgaben und Benutzerinhalte können alle eingefügte Anweisungen an das Modell enthalten. | Platzieren Sie eine Leitplanke im Pfad, wo immer dieser Inhalt das Modell erreichen kann. |
| 5. Zugangsdaten dürfen nicht in den Kabelbaum gelangen. | Die Schlüssel des KI-Anbieters in Prompt-Dateien und Agentenkonfigurationen sind ein leichtes Ziel für einen Angreifer. | Entfernen Sie sie und scannen Sie weiterhin die Kabelbaumdateien nach geheimen Informationen. Das lässt sich leicht beheben. |
Sichern Sie nicht nur das Modell, sondern auch den Gurt.
Xygeni KI-Sicherheit Es beginnt dort, wo die Entwicklung von Agenten-Harnesses ihre Spuren hinterlässt: in Ihren Repositories. Es erkennt die KI-Ressourcen in Ihrer Codebasis (Modelle, Agenten, MCP-Server, Skills, Prompts usw.). guardrails, und die verwendeten KI-Codierungswerkzeuge) aus Code, Abhängigkeiten und den Konfigurationsdateien, die diese Werkzeuge hinterlassen.
Anschließend analysiert es Skill-Dateien, Regeldateien und MCP-Konfigurationen als Sicherheitsartefakte (nicht als Dokumentation) und erkennt Risiken der Prompt-Injection-Klasse in der Agentenkonfiguration, beispielsweise wenn nicht vertrauenswürdige Inhalte eine Systemprompt oder eine Datenabfrage ohne Schutzmechanismen erreichen. Die Geheimnisprüfung von Xygeni kennzeichnet Anmeldeinformationen von KI-Anbietern in Prompts und Agentenkonfigurationsdateien. Die Abhängigkeiten Ihres KI-Stacks werden – noch bevor eine Signatur existiert – derselben Malware-Erkennung unterzogen wie alle anderen Komponenten.
FAQ
Was ist Agent Harness Engineering?
Agent Harness Engineering ist die Disziplin, die Umgebung eines KI-Modells (Anweisungen, Werkzeuge, Berechtigungen, Speicher, Kontext und Verifizierungsschleifen) so zu gestalten, dass es sich wie ein zuverlässiger Agent verhält. Das Modell liefert die Argumentationsfähigkeit; der Harness bestimmt, was der Agent sehen und tun kann.
Worin unterscheidet sich Agent Harness Engineering von Prompt Engineering?
Die Eingabeaufforderungsentwicklung formt eine einzelne Anweisung. Die Agenten-Harness-Entwicklung formt das gesamte System, in dem der Agent arbeitet, über viele Schritte, Werkzeuge und Sitzungen hinweg. Eine Eingabeaufforderung ist eine Datei im Harness.
Warum stellt das Geschirr ein Sicherheitsrisiko dar?
Da es die Aktionen eines Agenten steuert und in Klartextdateien gespeichert ist, die selten als Sicherheitsdokumente überprüft werden, ermöglicht die Kompromittierung einer Regeldatei oder einer MCP-Konfiguration die Kontrolle über den Agenten, ohne das Modell selbst zu verändern.
Wem sollte die Agentensicherheit gehören?
Anwendungssicherheit, Zusammenarbeit mit den Entwicklern, die Agenten erstellen und konfigurieren. Das Testsystem ist Teil der ausgelieferten Software und muss daher denselben Überprüfungs-, Scan- und Inventarisierungsprozessen unterzogen werden wie der übrige Code.
