Command Palette
Search for a command to run...
Nvidia Und Andere Stellen EvoSafeHarness Vor, Das Für Verschiedene KI-Agenten Automatisch Sicherheitsbarrieren Anpasst Und Die Angriffserfolgsrate Von 45,6 % Auf 10,0 % senkt.
Mit der Entwicklung großer Sprachmodelle von reinen Dialogsystemen hin zu Agenten, die Dateien, Konten, Datenbanken und externe Dienste aufrufen können, bekommt KI-Sicherheit auch konkretere reale Konsequenzen. Ein einzelner Fehler eines normalen Modells mag nur eine falsche Antwort erzeugen; wenn das Modell jedoch Werkzeuge aufrufen und Aktionen ausführen kann, kann derselbe Fehler reale Auswirkungen wie Überweisungen, Datenlecks oder Dateilöschungen haben. Zu diesem Zeitpunkt hat sich das Sicherheitsproblem vom Antwortinhalt auf den gesamten Aufgabenausführungsprozess ausgeweitet: Der Agent muss nicht nur die Absicht des Nutzers verstehen, sondern auch vermeiden, unter dem Einfluss falscher Anweisungen oder bösartiger Inhalte unbefugte Aktionen auszuführen.
Diese Art von Risiko stammt nicht nur von Nutzern. Angreifer können bösartige Anweisungen in externen Inhalten wie E-Mails, Webseiten oder Dokumenten verstecken; wenn der Agent diese liest, kann er Informationen, die eigentlich als Daten verarbeitet werden sollten, fälschlicherweise als neue Anweisungen interpretieren – das ist indirekte Prompt-Injection. Eine andere Art von Risiko stammt direkt aus der Anfrage des Nutzers selbst, zum Beispiel wenn der Agent aufgefordert wird, gefährliche oder unbefugte Aktionen auszuführen. Angesichts dieser Probleme haben Forscher die Verteidigungslinie zunehmend von der Modellinnenseite auf die Systemebene verlagert, indem sie einen Sicherheits-Harness zwischen Modell und Werkzeugen einfügen, der durch Berechtigungskontrolle, Prüfung von Werkzeugaufrufen und Überwachung des Ausführungsverlaufs das tatsächliche Verhalten einschränkt.
Das Problem ist, dass bestehende Harnesses meist von Experten vorab entworfen und dann für verschiedene Modelle und Geschäftsumgebungen wiederverwendet werden. Verschiedene Modelle unterscheiden sich stark in ihrer Fähigkeit, Angriffe abzuwehren, und verschiedene Domänen erfordern Aufmerksamkeit für unterschiedliche Risiken. Dateisysteme kümmern sich mehr darum, wie Befehle, Pfade und sensible Daten fließen; Finanzsysteme betreffen Geldflüsse, Transaktionsreihenfolgen und Kontostatus. Wenn dieselben Regeln einheitlich angewendet werden, können zu lockere Beschränkungen Angriffe nicht aufhalten, während zu strenge Beschränkungen normale Aufgaben beeinträchtigen.
Daraus ergibt sich, dass Forschungsteams der Johns Hopkins University, NVIDIA, der University of California, Berkeley und anderer Institutionen EvoSafeHarness vorgeschlagen haben, das den Sicherheits-Harness selbst zum Objekt automatischer Optimierung macht. Für verschiedene Modelle und Anwendungsdomänen durchsucht das System jeweils natürliche Sprachsicherheitsrichtlinien und ausführbare Codelogik und passt sie kontinuierlich an die tatsächlich aufgetretenen Fehler des Modells an. Die Forschung konzentriert sich nicht nur darauf, ob die Angriffserfolgsrate gesenkt werden kann, sondern auch darauf, ob der Agent nach der Hinzufügung der Verteidigung weiterhin normale Aufgaben erfüllen kann.
Die zugehörige Forschung wurde unter dem Titel „EvoSafeHarness: Evolving Model- and Domain-Specific Harnesses for Securing Agents" auf der Preprint-Plattform arXiv veröffentlicht.
Paper ansehen:
https://hyper.ai/papers/2609.05903
4 Kategorien von Sicherheits-Benchmarks decken 3 Arten von Geschäftsszenarien ab
Die Studie konzentriert die Evaluierung nicht auf einen einzelnen Datensatz, sondern verwendet vier Kategorien von Agenten-Sicherheits-Benchmarks: DecodingTrust-Agent, Agent-SafetyBench, AgentDojo / AgentDyn und AgentCanary. Sie decken jeweils domänen- und modellübergreifende Angriffe, Sicherheitsprobleme außerhalb von Werkzeugaufrufen, Übertragung auf ungesehene Umgebungen sowie adaptive Angriffe ab, bei denen Angreifer ihre Strategien aktiv anpassen.
Davon ist DecodingTrust-Agent Platform (DTAP) die Hauptexperimentierplattform. Die Studie wählt aus ihren 14 Domänen die drei Szenarien OS-Dateisystem, Finanzen und Telekommunikation aus und testet gleichzeitig direkte Angriffe und indirekte Prompt-Injection. Die bösartigen Ziele direkter Angriffe stammen aus der Anfrage des Nutzers selbst; indirekte Angriffe verstecken Anweisungen in Dateien, Tickets, Aufzeichnungen oder Nachrichten. Jede Domäne enthält 60 Suchaufgaben, davon jeweils 20 normale Aufgaben, direkte Angriffe und indirekte Angriffe; weitere 100 unabhängig zurückgehaltene Aufgaben werden für den finalen Test verwendet, auf die während der Suche nicht zugegriffen werden kann.
Agent-SafetyBench ergänzt Risiken außerhalb von Werkzeugaufrufen, wie etwa wenn Nutzer direkt unsichere Anfragen stellen oder der Agent in der finalen Antwort falsche Informationen verbreitet. Die Studie verwendet 48 Aufgaben für die Suche und testet auf 240 unabhängigen Aufgaben jeweils saubere Umgebungen, Kontextverschmutzung, indirekte Injection, Werkzeugmanipulation, Gedächtnisinjection und kombinierte Angriffe, was insgesamt 1.440 Test-Episoden ergibt.
AgentDojo und AgentDyn werden verwendet, um zu beobachten, ob sich die Verteidigung übertragen lässt. Der Harness wird nur auf AgentDojo mit Bank-, Slack-, Reise- und Arbeitsbereichsaufgaben gesucht und anschließend ohne Änderungen direkt auf die Shopping-, GitHub- und Alltagslebensumgebungen von AgentDyn angewendet. Da die Werkzeuge und Arbeitsabläufe der letzteren zuvor nie an der Suche teilgenommen haben, vermeidet dieses Setup, das „Sich-Merken spezifischer Werkzeugnamen" fälschlich als echte Generalisierungsfähigkeit zu interpretieren.
AgentCanary erhöht die Angriffsintensität weiter. Der Angreifer modifiziert die Prompts kontinuierlich basierend auf den tatsächlichen Antworten des Agenten aus der vorherigen Runde und versucht, neue Umgehungswege zu finden. Daher wird nicht nur die Verteidigungswirkung gegen eine feste Reihe von Angriffsbeispielen getestet, sondern wie viel Sicherheitsfähigkeit der Harness gegenüber aktiv adaptierenden Angreifern bewahren kann.
EvoSafeHarness: Zielmodell einfrieren, natürliche Sprachrichtlinien und ausführbaren Code gemeinsam optimieren
EvoSafeHarness führt kein Sicherheits-Feintuning am Ziel-Großsprachmodell durch; die Modellparameter bleiben während des gesamten Suchprozesses eingefroren. Was sich tatsächlich ändert, ist der Harness zwischen Nutzer, Modell und Werkzeugen – also die Systemebenlogik, die steuert, wie Informationen in das Modell gelangen, wie Werkzeugaufrufe ausgeführt werden und wie Ergebnisse zurückgegeben werden.
Die Forschung unterteilt Harness in zwei Teile: natürliche Sprachpolitik und ausführbaren Code. Die natürliche Sprachpolitik dient hauptsächlich dazu, klarzustellen, welche Informationen vertrauenswürdig sind, wie externe Inhalte behandelt werden sollten und in welchen Fällen eine Ablehnung erforderlich ist; der ausführbare Code kann Tool-Aufrufe direkt prüfen, modifizieren oder blockieren, während er frühere Aktionen aufzeichnet, Datenflüsse verfolgt und bei Bedarf ein Hilfs-Bewertungsmodell aufruft. Auf diese Weise können einige Sicherheitsbeschränkungen direkt in der Ausführungsphase verankert werden, ohne sich vollständig darauf zu verlassen, ob das Modell sich an die Anforderungen im Prompt erinnert.
Der gesamte Suchprozess wird von Designer, Criticizer, Cascade Test Environment und Analyzer gemeinsam durchgeführt. Der Designer liest die Bereichsspezifikationen, vorhandene Harness, historische Bewertungen und die früheren fehlgeschlagenen Ausführungspfade des Modells und ändert darauf basierend den Plan. Die Anpassung kann entweder eine neue Regel sein oder Änderungen an der Art der Zustandsaufzeichnung, der Prüfposition oder dem gesamten Kontrollfluss betreffen.
Bei der automatischen Suche tritt leicht ein Problem auf: Das System könnte versehentlich lernen, Regeln speziell für den Testdatensatz zu erstellen. Wenn beispielsweise bei einer Angriffsart immer wieder derselbe gefährliche Dateiname auftaucht, kann das direkte Aufnehmen dieses Dateinamens in eine Blacklist die Punktzahl schnell erhöhen, aber ein Angreifer kann ihn durch eine leichte Umbenennung umgehen. Um eine solche Überanpassung zu vermeiden, fügt die Forschung einen unabhängigen Criticizer hinzu. Dieser versucht, Pfade zu ändern, Dateipositionen zu verschieben oder Angriffsanweisungen umzuformulieren, und prüft, ob die Kandidatenregel weiterhin gültig ist. Wenn die Verteidigung von einem bestimmten konkreten String abhängt und nicht von relativ stabilen Beziehungen wie „ob diese Aktion vom Benutzer autorisiert wurde" oder „woher diese Informationen stammen", muss der Kandidatenplan weiter geändert werden.
Nach bestandener Prüfung gelangt der Harness in die Cascade Test Environment. Die Tests beginnen mit der Frage, ob der Code normal ausgeführt werden kann, und einer kleinen Anzahl von Aufgaben, und werden dann schrittweise ausgeweitet; offensichtlich schlechtere Pläne werden vorzeitig gestoppt, um keine weiteren Bewertungsressourcen zu verbrauchen. Der Analyzer zeichnet die Leistung bei normalen Aufgaben, direkten Angriffen und indirekten Angriffen separat auf, speichert gleichzeitig die konkreten Fehlschlagspfade und übergibt sie an den Designer für die nächste Runde der Anpassung.
Bei der Bewertung hat sich die Forschung nicht nur auf die Angriffserfolgsrate konzentriert. Sonst wäre der einfachste Sicherheitsansatz, alle Operationen abzulehnen – Angriffe könnten dann zwar nicht gelingen, aber der Agent verliert seinen Nutzen. EvoSafeHarness untersucht daher gleichzeitig die Erfüllung normaler Aufgaben und den Erfolg von Angriffen. Nur wenn die Angriffserfolgsrate gesenkt wird, während die Aufgabenfähigkeit im Wesentlichen erhalten bleibt, erhält der Kandidatenplan eine höhere Bewertung.
Die Suche beginnt auch nicht völlig bei Null. Die Forschung hat aus bestehenden Sicherheitsmethoden einige grundlegende Erfahrungen destilliert, z. B. dass Tool-Ausgaben standardmäßig als nicht vertrauenswürdige Daten gelten und vor der Ausführung einer Aktion geprüft werden sollte, ob sie der ursprünglichen Benutzeranfrage entspricht. Diese Erfahrungen dienen jedoch nur als Ausgangspunkt; die spätere Suche kann sie beibehalten, neu kombinieren oder entfernen. Einige finale Harness basieren weiterhin hauptsächlich auf natürlicher Sprachpolitik, andere stützen sich stärker auf programmatische Regeln, und wieder andere integrieren schrittübergreifende Zustandsaufzeichnungen und Datenflussverfolgung.
Hier zeigt sich auch die grundlegende Idee dieser Arbeit: Die Risikostrukturen in den Bereichen Dateisystem, Finanzen und Telekommunikation sind unterschiedlich, und auch das eigene Verhaltensmuster des Modells beeinflusst die Verteidigungsweise. Das Dateisystem erfordert die Prüfung von Befehlen, Pfaden und sensiblen Datenflüssen; im Finanzbereich geht es eher um Transaktionsrichtungen, Geldflüsse und die Beziehungen zwischen mehreren Operationen. Konkret auf die Modelle bezogen: Manche Modelle versuchen es nach einer Ablehnung wiederholt, andere suchen alternative Wege, und wieder andere senden mehrere gleichzeitige Aufrufe – der Harness muss daher unterschiedlich angepasst werden.
Am Beispiel des OS-Dateisystems: Bei derselben bösartigen Dateikopieranweisung benötigt Sonnet 4.6 lediglich eine Quellen-Erinnerung und einige semantische Prüfungen; GLM-5 hingegen benötigt zusätzliche Prüfungen für gefährliche Befehle, sensible Speicherorte, vertrauliche Informationen und Datenflüsse. Wenn man GLM-5 festlegt und zum Finanzszenario wechselt, prüft der Harness wiederum Geldabflüsse, Empfängerobjekte und historische Transaktionen, da das Risiko von mehreren Operationen ausgehen kann, die einzeln betrachtet normal, in Kombination jedoch problematisch sind.
In 14 der 15 „Modell × Bereich"-Kombinationen am besten abgeschnitten
Die Forscher testeten zunächst Sonnet 4.6, GLM-5, Kimi-K2.5, Qwen3.7-plus und DeepSeek-V4-Flash – insgesamt 5 Modelle – auf DTAP und suchten jeweils in den 3 Bereichen OS-Dateisystem, Finanzen und Telekommunikation nach Harness, wodurch 15 „Modell × Bereich"-Kombinationen entstanden.
Ohne Verteidigung zeigen die 5 Modelle bereits große Sicherheitsunterschiede. Die durchschnittliche Angriffserfolgsrate (ASR) von Sonnet 4.6 liegt nur bei 4,8 %, während DeepSeek-V4-Flash 71,0 % erreicht. Die Wirkung fester Verteidigungen ist ebenfalls bereichsabhängig: CaMeL und DRIFT schneiden im Dateisystem relativ gut ab, aber in den Szenarien Finanzen und Telekommunikation lässt die Verteidigungsfähigkeit deutlich nach.
EvoSafeHarness erzielte in 14 von 15 Kombinationen die höchste Gesamtpunktzahl. Die durchschnittliche Angriffs-Erfolgsrate (ASR) sank von 45,6 % ohne Verteidigung auf 10,0 %, während die Nutzbarkeit für normale Aufgaben nur um 3,3 Prozentpunkte zurückging. Zum Vergleich: Die durchschnittliche ASR von CaMeL und DRIFT lag weiterhin bei 37,7 % bzw. 42,4 %; Progent konnte die ASR auf 10,5 % senken, aber die Nutzbarkeit für normale Aufgaben fiel auf 56,4 %, während EvoSafeHarness bei 79,8 % lag. Betrachtet man die beiden Angriffsarten getrennt, sank die ASR bei direkten Angriffen von 50,9 % auf 12,6 %, bei indirekten Angriffen von 40,4 % auf 7,4 %.
Diese Ergebnisse korrespondieren mit den zuvor genannten Modellunterschieden. Bei denselben Dateisystem-Angriffen erzielt Sonnet 4.6 mit leichteren semantischen Urteilen eine niedrigere ASR, während GLM-5 mehr deterministische Prüfungen und Zustandsverfolgung benötigt. Mit dem Domänenwechsel ändert sich auch das Objekt der Sicherheitsbeurteilung: Im Dateisystem wird hauptsächlich geprüft, ob eine Aktion gefährliche Befehle oder sensible Daten berührt; im Finanzszenario müssen zusätzlich frühere Transaktionsaufzeichnungen berücksichtigt werden, um zu beurteilen, ob mehrere Aktionen in Kombination Wash-Trades oder Kapitalabzug bilden.
Auf Agent-SafetyBench testete die Studie weiterhin Sicherheitsprobleme, die sich nicht unbedingt über Tool-Aufrufe manifestieren. Im Durchschnitt der 3 Modelle betrug die Rate unsicheren Verhaltens von EvoSafeHarness 12,3 %, die Angriffs-Erfolgsrate 7,4 % und die Nutzbarkeit in Angriffsumgebungen 63,4 %. Die Ergebnisse zeigen, dass die Verbesserung der Sicherheitskennzahlen nicht mit einer massiven Ablehnung normaler Aufgaben einherging.
Die Transfer-Experimente prüften direkter, ob das Harness von den beim Training gesehenen Tools abhängig ist. EvoSafeHarness wurde nur auf AgentDojo trainiert und erzielte in diesem Benchmark eine Nutzbarkeit von 82,8 % und eine ASR von 0 %; Anschließend wurde dasselbe Harness direkt auf AgentDyn angewendet und behielt eine Nutzbarkeit von 75,0 % und eine ASR von 0 % bei. CaMeL erreichte auf AgentDyn ebenfalls eine ASR von 0 %, aber die Nutzbarkeit für normale Aufgaben sank gleichzeitig auf 0 %. Das zeigt: Es ist nicht schwer, alle Risiken gemeinsam zu blockieren, sondern es ist schwer, Angriffe zu verhindern und dem Agenten gleichzeitig zu ermöglichen, normale Arbeit fortzusetzen.
Bei den adaptiven Angriffen auf AgentCanary sank die ASR unter statischen Angriffsbedingungen von 23,6 % auf 9,7 %. Als der Angreifer die Prompts kontinuierlich basierend auf System-Feedback modifizierte, stieg die Angriffs-Erfolgsrate wieder an; bei maximal 16 Modifikationsrunden lag die durchschnittliche ASR der 3 Angreifer bei 19,5 %. Obwohl einige Angriffe neue Umgehungswege fanden, versagte die Verteidigung nicht sofort aufgrund von Änderungen in der Angriffsformulierung.
Schließlich führte die Studie statistische Tests an 1.050 gepaarten Angriffsaufgaben im DTAP durch. In 13 der 15 Modell-Domänen-Kombinationen sank die Angriffs-Erfolgsrate signifikant; in den anderen 2 Kombinationen konnten die Modelle bereits die überwiegende Mehrheit der Angriffe abwehren. Über alle Aufgaben hinweg verhinderte EvoSafeHarness 385 ursprünglich erfolgreiche Angriffe und erzeugte nur 11 neue erfolgreiche Angriffsfälle. Die statistischen Ergebnisse stützen, dass diese Veränderung keine zufällige Schwankung ist.
Gleichzeitig überlappten sich die Konfidenzintervalle der Nutzbarkeit normaler Aufgaben in allen 15 Kombinationen mit dem Zustand ohne Verteidigung. Mit anderen Worten: Die in der Arbeit beobachtete Sicherheitsverbesserung wurde nicht durch eine massive Schwächung der Fähigkeiten für normale Aufgaben erkauft. Für Agenten, die tatsächlich in reale Umgebungen eingesetzt werden sollen, ist dies wichtiger als das bloße Streben nach einer niedrigeren Angriffs-Erfolgsrate.
Fazit
EvoSafeHarness bietet einen anderen Ansatz als das „einheitliche Guardrail“: Sobald der Agent in eine spezifische Geschäftsumgebung eintritt, können die Sicherheitsbeschränkungen basierend auf Modellverhalten und Domänenrisiken neu gestaltet werden, anstatt dieselben Regeln auf alle Systeme anzuwenden. Die Studie zeigt auch, dass für die Verteidigungswirkung oft nicht die Anzahl der Regeln entscheidend ist, sondern ob die Regeln den tatsächlichen Risiken entsprechen, ob die Prüfungen an den richtigen Stellen platziert sind und ob das System genügend Kontextzustand beibehält.
Natürlich hat diese Methode auch Grenzen: Für Risiken wie Faktenfehler oder irreführende Aussagen, die hauptsächlich auf Inhaltsebene auftreten, kann ein systemseitiges Harness ohne direkt prüfbare Aktionen, Berechtigungen oder Zustandsbeziehungen weiterhin nur schwer eine vollständige Lösung bieten. Mit der weiteren Integration von Agenten in reale Geschäftssysteme könnte die Frage, wie die eigenen Sicherheitsfähigkeiten des Modells, Domänenregeln und Ausführungsebenen-Beschränkungen zusammenwirken können, zu einem lohnenderen Thema für kontinuierliche Forschung werden.