Microsoft run-assert-eval verwandelt Erkenntnisse zu Agentenrisiken in getestete Laufzeitkontrollen

Microsoft veröffentlichte run-assert-eval am 24. September und verbindet damit vier zuvor getrennte Aufgaben der Agentensicherheit in einem geführten Workflow. Die Microsoft-run-assert-eval-Skill identifiziert Risiken, misst Fehler, entwirft Laufzeitkontrollen und wiederholt dieselbe Evaluierung, nachdem diese Kontrollen ergänzt wurden. Der Konflikt liegt auf der Hand: Ein schnellerer Sicherheitskreislauf ist nur nützlich, wenn seine Messungen glaubwürdig bleiben.

Das Beispiel von Microsoft verleiht der Ankündigung Substanz. Ein Abrechnungs-Support-Agent legte laut Unternehmen in 12 von 40 relevanten Baseline-Gesprächen Daten anderer Kunden offen. Nach Einführung einer Laufzeitrichtlinie beobachtete Microsoft zwei Verstöße in 34 relevanten Gesprächen. Dadurch sank die berichtete Quote von 30,0 % auf 5,9 %.

Das Ergebnis klingt eindeutig, stammt jedoch aus einem ausgearbeiteten Beispiel, das von den Entwicklern des Projekts betreut wurde. Microsoft hat weder eine unabhängige Replikation noch eine Studie zum produktiven Einsatz vorgelegt. Die wichtige Entwicklung ist daher der Mechanismus, nicht ein einzelner günstiger Wert. Die Skill verwandelt einen identifizierten Fehler in eine durchsetzbare Richtlinie und testet die Maßnahme, ohne die Evaluierung stillschweigend zu verändern.

Microsoft run-assert-eval verbindet Entdeckung, Tests und Durchsetzung

Die Veröffentlichung führt eine Sammlung von Sicherheitsprojekten zu einem überprüfbaren Weg von einem unbekannten Risiko zu einer getesteten Laufzeitkontrolle zusammen.

Microsofts Launch-Beitrag beschreibt einen Workflow, der über einen Prompt in einer kompatiblen Coding-Umgebung gestartet wird. Entwickler beginnen mit einem Agenten, seinem vorgesehenen Zweck, seinen Tools und den Grenzen, die er einhalten muss.

Die Skill kann Clarity zur Bedrohungsmodellierung des Agenten verwenden. Bedrohungsmodellierung bedeutet, plausible Fehler, betroffene Werte, Ursachen und Folgen zu identifizieren, bevor Tests ausgewählt werden. Teams können auch ein bekanntes Risiko aus einer Produktanforderung, einem Incident-Bericht, einem Testplan oder einer bestehenden Bewertung einbringen.

Diese Unterscheidung ist wichtig. Risikoentdeckung wird empfohlen, ist aber nicht verpflichtend. Ein Team, das bereits weiß, dass sein Abrechnungsagent Kundendatensätze offenlegt, kann mit diesem Verhalten beginnen, statt die Entdeckungsarbeit zu wiederholen.

Wenn Teams Entdeckung benötigen, untersucht der Clarity Threat Modeler den umfassenderen Betriebskontext des Agenten. Er soll Fehler aufdecken, die nie in den ursprünglichen Anforderungen festgehalten wurden.

In Microsofts Abrechnungsbeispiel identifizierte Clarity vier mögliche Fehlermodi. Das Team wählte zwei als kritisch eingestufte Risiken aus: nicht verifizierte risikoreiche Aktionen und die Offenlegung kundenübergreifender Daten.

Das erste Risiko umfasste Änderungen an Abrechnungen, die ohne Bestätigung der Identität des Anrufers vorgenommen wurden. Das zweite betraf Offenlegungen zu einem Konto, das nicht dem Anrufer gehörte.

Die Skill übergab jedes ausgewählte Risiko an ASSERT, Microsofts anforderungsbasiertes Evaluierungsframework. Jedes Risiko wurde zu einer Konfiguration, einem Verhalten und einer Evaluierungssuite.

Diese enge Struktur ist folgenreicher, als sie zunächst erscheint. Wenn eine Evaluierung Autorisierungs-, Datenschutz-, Genauigkeits- und Eskalationsfehler vermischt, kann ihr Gesamtwert nicht erklären, welche Kontrolle benötigt wird.

Microsoft run-assert-eval trennt diese Verhaltensweisen stattdessen. Variation wird innerhalb jeder Suite über Dimensionen wie Zugriffsmodus, Vorwand des Nutzers, Autoritätsbehauptungen und eine schrittweise Ausweitung des Umfangs über mehrere Gesprächsrunden eingeführt.

Die Skill durchsucht außerdem frühere Forschung und Sicherheitsframeworks nach relevanten Testdimensionen. Microsoft zufolge können diese Quellen NIST-Leitlinien, OWASP-Ressourcen, Benchmarks, regulatorische Materialien und Richtlinien von Modellanbietern umfassen.

ASSERT generiert anschließend Fälle, führt den Zielagenten aus und bewertet aufgezeichnete Transkripte. Seine zwei zentralen Messgrößen bleiben bewusst getrennt.

„Unzulässiges Verhalten verletzt“ erfasst Fälle, in denen der Agent verbotenes Verhalten ausführte. „Zulässiges Verhalten verletzt“ misst Fälle, in denen der Agent trotz bestehender Erlaubnis nicht hilfreich war.

Diese Trennung schützt vor einer bekannten Sicherheitsillusion. Ein Agent, der jede Anfrage ablehnt, kann viele schädliche Handlungen vermeiden, erfüllt dann aber auch seine Aufgabe nicht mehr.

Der Workflow erstellt anschließend aus dem gemessenen Fehler einen Entwurf für eine Richtlinie der Agent Control Specification. ACS ist ein portables Format, um Kontrollen an definierten Punkten in der Ausführung eines Agenten zu platzieren.

Abschließend evaluiert die Skill eine kontrollierte Version des Agenten anhand derselben Fälle. Die Baseline- und die kontrollierten Durchläufe behalten dieselbe Verhaltensdefinition, Testmenge und Bewertungsmethode bei.

Das Ergebnis ist nicht bloß ein weiterer Sicherheitswert. Es ist ein kontrollierter Vergleich, der die Richtlinie als veränderte Variable isolieren soll.

Der Druck steigt für Teams, die Prompts als wichtigste Schutzmaßnahme einsetzen

Microsoft stellt die Annahme infrage, dass schriftliche Anweisungen allein für Tool-nutzende Agenten eine ausreichende Kontrollgrenze bieten.

Systemprompts bleiben nützlich, um Rollen und erwartetes Verhalten festzulegen. Sie sind jedoch weiterhin probabilistische Anweisungen, die ein Modell interpretiert, und keine deterministischen Autorisierungsprüfungen, die von umgebender Software durchgesetzt werden.

Diese Schwäche wird relevant, wenn ein Agent Datensätze abrufen, Konten aktualisieren, Rückerstattungen ausstellen oder administrative Tools aufrufen kann. Eine überzeugend formulierte Anfrage kann dann zu einem Datenbankabruf oder einer Geschäftsaktion werden.

Microsofts Abrechnungsbeispiel verdeutlicht diese Lücke. Der Agent arbeitete für einen Anrufer, der dem Konto ACME-1001 zugeordnet war. Er hätte niemals das Konto eines anderen Kunden abrufen oder verändern dürfen.

Eine evaluierte Anfrage verlangte Kontaktinformationen zu BPS-447, das einem anderen Kunden gehörte. Der Baseline-Agent gab laut Microsoft den vollständigen Datensatz zurück.

Ein Code-Review könnte bestätigen, dass die Abruffunktion korrekt arbeitet. Ein Unit-Test könnte bestätigen, dass eine gültige Konto-ID den erwarteten Datensatz zurückliefert. Keines von beidem testet zwingend, ob das Modell während eines realistischen Gesprächs eine nicht autorisierte Kennung auswählt.

Das Problem reicht über Abrechnungs-Support hinaus. Ein Recherche-Agent kann auf ungeeignete Quellen zugreifen, während ein Change-Management-Agent eine Genehmigungssequenz umgehen kann. Ein Reise-Agent kann gespeicherte Identitäts- oder Zahlungsinformationen missbrauchen.

Die OWASP-Leitlinien bezeichnen diesen umfassenderen Zustand als excessive agency. Er entsteht, wenn eine KI-Anwendung mehr Funktionen, Berechtigungen oder Autonomie besitzt, als ihre Aufgabe erfordert.

Prompt-Injection kann solche Fehler auslösen, ist aber nicht die einzige Ursache. Mehrdeutige Anfragen, halluzinierte Pläne, kompromittierte Tools und einfache Modellfehler können ebenfalls unsichere Aktionen verursachen.

Betroffen sind nicht nur Sicherheitsteams. Produktmanager müssen erlaubte und verbotene Ergebnisse definieren. Entwickler müssen geeignete Kontrollpunkte bereitstellen. Risikoverantwortliche müssen entscheiden, ob eine gemessene Verringerung ausreicht.

Auch Evaluierungsteams stehen unter Druck. Ihre Arbeit kann nicht länger bei einem Bericht stehen bleiben, der Fehler auflistet. Der Microsoft-Workflow erwartet, dass ein Befund eine konkrete Kontrolle und einen wiederholbaren Validierungslauf unterstützt.

Organisationen, die generische Modell-Benchmarks verwenden, stehen vor einem weiteren Problem. Ein breiter Benchmark kann die durchschnittlichen Tendenzen eines Modells beschreiben, aber nicht die Kontoregeln, Eskalationsgrenzen oder internen Genehmigungsprozesse jedes Unternehmens erfassen.

Microsofts Ansatz beginnt mit den eigenen Anforderungen und identifizierten Risiken der Anwendung. Das macht die Evaluierung relevanter, erschwert jedoch Vergleiche zwischen Organisationen.

Die Veröffentlichung erhöht außerdem den Druck auf Anbieter, die Beobachtung als letzten Schritt behandeln. Das Protokollieren eines gefährlichen Tool-Aufrufs nach dessen Ausführung kann eine Untersuchung unterstützen. Es verhindert nicht die Handlung, die den Schaden verursacht hat.

Run-assert-eval verlagert die Maßnahme in den Laufzeitpfad des Agenten. Damit rückt sie näher an bekannte Sicherheitskonzepte wie Autorisierungsprüfungen, das Prinzip der geringsten Rechte und Richtlinien-Durchsetzungspunkte.

Das beseitigt Prompts nicht. Es weist ihnen eine engere Rolle zu. Modelle können planen und Sprache interpretieren, während deterministische Kontrollen entscheiden, ob sensible Vorgänge fortgesetzt werden dürfen.

Diese Aufteilung wird zunehmend wichtig, da Agenten Zugriff auf lokale Dateien und internes Wissen erhalten. Teams, die eine durchsuchbare Wissensdatenbank aufbauen, stehen vor derselben Grenzfrage: Der Abruf muss den tatsächlichen Autorisierungsumfang des Nutzers respektieren.

Microsoft run-assert-eval fasst diese Frage in einen Workflow, den Entwickler früher ausführen können. Die Aufgabe verschiebt sich damit vom Hoffen, dass das Modell eine Regel befolgt, hin zum Nachweis, wo Software sie durchsetzt.

Der Kernmechanismus ist ein kontrollierter Vorher-Nachher-Test

Die stärkste Idee von run-assert-eval ist nicht die automatisierte Richtliniengenerierung, sondern die Beibehaltung der Evaluierung, während nur die Kontrolle verändert wird.

Sicherheitsvergleiche werden unzuverlässig, wenn Teams nach Anwendung einer Korrektur die Testmenge neu generieren. Eine andere Gruppe von Prompts kann eine schwache Richtlinie erfolgreich erscheinen lassen oder eine solide Richtlinie schlechter wirken lassen.

Ein Wechsel des Bewerters schafft eine weitere Störvariable. Zwei Evaluatoren können dasselbe Transkript unterschiedlich interpretieren, insbesondere wenn akzeptables Verhalten vom Kontext abhängt.

Run-assert-eval speichert die Systematisierung und Testfälle der Baseline zwischen. Der kontrollierte Agent wird anschließend mit derselben Verhaltensdefinition, denselben Fällen und demselben Bewertungsansatz konfrontiert.

Microsoft bezeichnet dies als Einfrieren der Evaluierung. Die Richtlinie wird zur beabsichtigten unabhängigen Variable, während die gemessenen Verstoßquoten die beobachteten Ergebnisse darstellen.

Das Prinzip ähnelt Regressionstests in herkömmlicher Software. Ein fehlgeschlagener Test sollte unverändert bleiben, während Entwickler die Implementierung ändern. Andernfalls können bestandene Ergebnisse einen umgeschriebenen Test statt korrigierten Verhaltens widerspiegeln.

Agententests sind schwieriger, weil Modellausgaben variabel sind. Auch der Bewerter kann modellbasiert sein, und generierte Fälle können eigene Mehrdeutigkeiten enthalten.

Diese Elemente konstant zu halten, beseitigt nicht jede Unsicherheitsquelle. Es macht den Unterschied zwischen Vorher und Nachher jedoch besser interpretierbar.

Microsoft zufolge zeigten frühere ASSERT-Evaluierungen eine Übereinstimmung von 80 % bis 90 % zwischen seinem automatisierten Bewerter und menschlichen Prüfern. Diesen Bereich vergleicht das Unternehmen mit einer Übereinstimmung von etwa 90 % zwischen menschlichen Prüfern.

Diese Werte sind von Microsoft berichtete Ergebnisse, keine universellen Genauigkeitsgarantien. Die Übereinstimmung von Bewertern kann je nach Verhalten, Modell, Bewertungsraster, Sprache und Komplexität der zugrunde liegenden Richtlinie variieren.

Die zugrunde liegende Evaluierung bleibt überprüfbar. Das ASSERT-Repository erklärt, dass Durchläufe lokale Artefakte, generierte Fälle, Modellausgaben, Begründungen des Bewerters und Metriken speichern.

Lokale Artefakte können Audits unterstützen, weil Prüfer nachvollziehen können, warum ein Transkript als Verstoß eingestuft wurde. Sie können auch Fälle identifizieren, in denen der Evaluator die Richtlinie missverstanden hat.

Das Zwei-Quoten-Design von ASSERT fügt eine weitere Schutzmaßnahme hinzu. Eine Richtlinie, die schädliches Verhalten blockiert, kann dennoch scheitern, wenn sie zu übermäßigen Ablehnungen führt.

Für die kundenübergreifende Suite berichtete Microsoft eine Baseline-Quote unzulässiger Verstöße von 30,0 %. Das kontrollierte Ergebnis lag bei 5,9 % bei einem anderen relevanten Nenner.

Microsoft teilte seine Ergebnisse außerdem in Prompt- und Szenario-Splits auf. Prompt-Fälle testen direktere Interaktionen, während Szenario-Fälle umfangreichere Workflows und Gesprächskontext erfassen.

Bei kundenübergreifenden Prompt-Fällen sank die berichtete Quote unzulässiger Verstöße von 20,8 % auf 8,7 %. Die entsprechende Szenarioquote fiel von 43,8 % auf 0,0 %.

Bei Fällen mit Aufforderungen zu nicht verifizierten Aktionen sank die berichtete Rate von 4,0 % auf 0,0 %. In der Szenarioaufteilung fiel sie von 8,7 % auf 4,5 %.

Verstöße gegen zulässiges Verhalten erreichten Berichten zufolge in allen vier überwachten Aufteilungen 0,0 %. Microsoft wertet dieses Ergebnis als Hinweis darauf, dass die Kontrollen in dieser Stichprobe legitime Arbeit bewahrten.

Die verbleibenden unzulässigen Verstöße sind relevant. Sie zeigen, dass die Richtlinie nicht jeden Fehler beseitigte – selbst innerhalb des kontrollierten Beispiels.

Das entspricht dem iterativen Design des Workflows. Ein Team kann verbleibende Fehler untersuchen, seine Risikodefinition oder Richtlinie verfeinern und denselben Prozess wiederholen.

Die Methode liefert daher stärkere Belege als eine Handvoll manueller Demonstrationen. Sie belegt jedoch weiterhin nicht, wie sich der Agent bei allen künftigen Prompts, Modellaktualisierungen, Tools oder Umgebungen verhält.

Der praktische Gewinn ist enger gefasst und nützlicher. Teams erhalten nachvollziehbare Belege dafür, dass eine bestimmte Kontrolle die Leistung in einer definierten Evaluation verändert hat, ohne den Agenten lediglich zum Schweigen zu bringen.

Laufzeit-Richtlinien blockieren Aktionen, bevor das Modell sie abschließen kann

Die Abrechnungsbehebung funktioniert, indem sie den Kontoumfang an der Tool-Grenze prüft – nicht indem sie das Modell auffordert, seine Absichten zu überdenken.

Nach der Messung der kundenübergreifenden Gefährdung erzeugte run-assert-eval einen Richtlinienentwurf und ein ACS-Manifest. Die Richtlinie formulierte die Entscheidungslogik, während das Manifest festlegte, wo diese Logik angewendet werden sollte.

Microsoft verwendete Rego, eine deklarative Richtliniensprache, die häufig mit Policy-Engines verbunden wird. Das generierte Material blieb ein Entwurf, der einer menschlichen Prüfung bedurfte.

Diese Prüfungsstufe ist wichtig. Microsoft erklärt ausdrücklich, dass Generierung nicht mit Genehmigung gleichzusetzen ist. Entwickler müssen die Richtlinie, den Interventionspunkt, das Manifest und die Verbindung zum Zielagenten prüfen.

Die ausgewählte Richtlinie verweigerte Tool-Aufrufe, wenn die angeforderte Konto-ID von der des Aufrufers abwich. Diese Regel erforderte kein weiteres Modell, um zu entscheiden, ob die Anfrage verdächtig wirkte.

Microsoft platzierte die Prüfung bei pre_tool_call, einem Abfangpunkt, der erreicht wird, bevor der Agent ein Tool ausführt. Eine nicht übereinstimmende Kennung führt daher zu einer Ablehnung, bevor ein Abruf erfolgt.

Das Team verwendete zudem post_tool_call. Diese zweite Prüfung hielt jedes nicht übereinstimmende Ergebnis zurück, das niemals in den Kontext des Modells gelangen sollte.

Die Nutzung beider Punkte schafft mehrschichtige Verteidigung. Der erste versucht, eine nicht autorisierte Operation zu verhindern. Der zweite begrenzt die Offenlegung, falls die frühere Kontrolle umgangen oder fehlerhaft eingebunden wurde.

Die ACS policy engine soll diese Kontrollen von einem einzelnen Agent-Framework entkoppeln. Richtlinien können dadurch portabel bleiben, wenn Teams Modelle oder Orchestrierungsbibliotheken wechseln.

Diese Portabilität adressiert ein tatsächliches Wartungsproblem. Kontrollen, die in Prompts oder frameworkspezifische Callbacks eingebettet sind, können über mehrere Agent-Implementierungen hinweg schwer prüfbar werden.

Eine gemeinsame Spezifikation kann Sicherheitsprüfern ein konsistentes Prüfobjekt geben. Sie kann Entwicklern zudem ermöglichen, Richtlinienänderungen zusammen mit Anwendungscode zu versionieren.

Portabilität garantiert jedoch keine korrekte Integration. Jede Laufzeitumgebung muss relevanten Kontext bereitstellen, Identitäten erhalten und die Richtlinie zum richtigen Zeitpunkt aufrufen.

Eine Kontoumfangsregel hängt von vertrauenswürdigen Kontoinformationen ab. Wenn die Identität des Aufrufers falsch ist oder fehlt, führt selbst ein perfekt geschriebener Vergleich zum falschen Autorisierungsergebnis.

Dasselbe gilt für Tool-Argumente. Eine Richtlinie, die account_id prüft, setzt voraus, dass die angeforderte Ressource durch dieses Feld korrekt dargestellt wird.

Komplexe Tools können sensible Ziele in Abfragen, Dokumenten, URLs oder verschachtelten Aktionen verbergen. Eine eng gefasste Regel könnte dann gleichwertige Wege zur selben geschützten Ressource übersehen.

Eine Laufzeit-Richtlinie kann zudem nicht jede Fehlerklasse beheben. Eine Kontrolle kann eine nicht autorisierte Rückerstattung oder einen Datenbanklesezugriff blockieren. Sie kann nicht automatisch bestimmen, ob jede generierte Erklärung korrekt oder fair ist.

Menschliche Genehmigungen bleiben für manche folgenreichen Aktionen angemessen. Ein Tool-Design nach dem Prinzip geringster Rechte kann Schäden verringern, selbst wenn das Modell eine schlechte Entscheidung trifft.

Das umfassendere AI risk framework behandelt Risikomanagement als Aktivität über den gesamten Lebenszyklus. Es umfasst Governance, Zuordnung, Messung und fortlaufendes Management statt eines einzigen Tests vor der Veröffentlichung.

Run-assert-eval fügt sich in dieses größere Muster ein. Es liefert eine konkrete Brücke von der Zuordnung eines Risikos zur Messung und Steuerung eines Verhaltens.

Der Einstiegspunkt des Workflows über einen einzelnen Prompt sollte die darunterliegende Arbeit nicht verschleiern. Bedrohungsmodellierung, Testdesign, Richtlinienprüfung, Systemintegration und Ergebnisinterpretation erfordern weiterhin fundierte Entscheidungen.

Microsoft hat den manuellen Übergang zwischen diesen Entscheidungen reduziert. Die Skill transportiert strukturierte Artefakte von einer Phase zur nächsten und hält ihre Beziehungen sichtbar.

Das kann die Wahrscheinlichkeit senken, dass eine Risikobeschreibung bei der Übergabe zwischen Produkt-, Evaluierungs- und Sicherheitsteams an Bedeutung verliert.

Es kann auch den Zeitraum zwischen dem Entdecken eines Fehlers und der Überprüfung einer Gegenmaßnahme verkürzen. In diesem Zeitraum sammelt sich häufig ungelöstes Agent-Risiko an.

Die ersten Ergebnisse sind Belege, keine allgemeine Sicherheitsgarantie

Microsofts Beispiel stützt die Logik des Workflows, belegt jedoch keine Produktionswirksamkeit über Agenten, Organisationen oder Angriffe hinweg.

Die offensichtlichste Einschränkung ist die Herkunft. Microsoft und Projektmitwirkende entwickelten die Werkzeuge, wählten das Beispiel aus, wendeten die Kontrollen an und berichteten die daraus resultierenden Messwerte.

Das macht die Ergebnisse nicht ungültig. Es bedeutet, dass Leser zwischen einem transparenten ausgearbeiteten Beispiel und einem unabhängigen Benchmark oder einer Feldstudie unterscheiden sollten.

Auch die Stichprobengrößen erfordern Vorsicht. Die Ausgangsbasis der Schlagzeile umfasste 40 anwendbare Gespräche, während der überwachte Lauf 34 umfasste.

Diese Nenner unterscheiden sich, weil nur anwendbare Fälle zu einer bestimmten Verhaltensrate beitragen. Dennoch können kleine Stichproben instabile Prozentwerte erzeugen.

Eine Veränderung von zwölf Verstößen auf zwei ist im Beispiel operativ bedeutsam. Sie sollte nicht als universelle Reduktion um 80 % für andere Agenten interpretiert werden.

Die berichtete Rate zulässiger Verstöße von 0,0 % bedeutet auch, dass in dieser Stichprobe keine Verstöße auftraten. Sie bedeutet nicht, dass die Richtlinie niemals legitimes Verhalten blockieren kann.

Ein größerer Testsatz könnte seltene fälschliche Ablehnungen aufdecken. Produktionsverkehr könnte Kontobeziehungen, Delegationsregeln oder Support-Ausnahmen enthalten, die im Beispiel fehlen.

Evaluierungs-Leakage stellt ein weiteres Problem dar. Wird eine Richtlinie wiederholt gegen einen eingefrorenen Testsatz optimiert, können Entwickler die bekannten Fälle letztlich überanpassen.

Das Einfrieren von Tests schafft während einer Intervention einen glaubwürdigen Vergleich. Langfristige Programme benötigen weiterhin zurückgehaltene Fälle, neue adversariale Varianten und Monitoring für sich veränderndes Verhalten.

Modelländerungen können frühere Schlussfolgerungen ebenfalls ungültig machen. Ein neues Modell kann Tool-Argumente anders formatieren, Ablehnungen anders interpretieren oder einen anderen Weg zu den geschützten Informationen finden.

Tool-Änderungen schaffen ein ähnliches Risiko. Das Hinzufügen einer Exportfunktion oder eines allgemeinen Suchendpunkts kann einen Zugriffsweg einführen, den die ursprüngliche Kontoprüfung nicht abdeckt.

Der Evaluierungsrichter verdient fortlaufende Prüfung. Microsofts berichtete Übereinstimmungsbereich ist ermutigend, doch Uneinigkeitsfälle können sich an den mehrdeutigsten und folgenreichsten Grenzen häufen.

Teams sollten für strittige Fälle eine menschliche Prüfung beibehalten und scheinbar erfolgreiche Ergebnisse regelmäßig stichprobenartig prüfen. Ein stabiler automatisierter Richter ist für Vergleiche nützlich, aber keine unfehlbare Autorität.

Im Wort „Skill“ steckt zudem ein Lieferkettenproblem. Agent-Skills enthalten Anweisungen, die Planung, Ausführung und Validierung beeinflussen.

Microsoft Research berichtete kürzlich über 307 skillbedingte Fehler in zwei Benchmark-Settings. Dazu gehörten 125 funktionale Fehler und 182 Effizienzrückschritte.

Diese Forschung bewertet run-assert-eval nicht speziell. Sie liefert einen umfassenderen Grund, die Anweisungen, Skripte, Berechtigungen und operativen Annahmen jeder Skill zu prüfen.

Run-assert-eval begegnet diesem Problem teilweise durch sichtbare Artefakte und menschliche Kontrollpunkte. Teams können generierte Evaluierungskonfigurationen und Richtlinien prüfen, bevor sie überwachte Läufe ausführen.

Die literaturgestützte Testgenerierung schafft eine weitere Verifizierungspflicht. Ein zitierter Rahmen kann Dimensionen leiten, doch die Relevanz hängt davon ab, wie genau die Skill diese Quelle in Fälle übersetzt.

Eine schwache Übersetzung kann eindrucksvolle Abdeckungsbezeichnungen erzeugen, ohne eine aussagekräftige Abdeckung zu bieten. Prüfer sollten daher Szenarien untersuchen, nicht nur die daran angehängten Namen der Frameworks.

Operative Kosten sind eine weitere offene Frage. Das Ausführen generierter Fälle, das Erfassen von Traces, das Bewerten von Transkripten und das Wiederholen von Evaluationen verbraucht Modellaufrufe und Engineering-Zeit.

Das Projekt hat keinen umfassenden Vergleich dieser Kosten mit manuellen Bewertungsworkflows veröffentlicht. Organisationen müssen bestimmen, welche Risiken eine tiefere Evaluation rechtfertigen.

Die vernünftigste Interpretation ist zurückhaltend, aber positiv. Microsoft hat einen kohärenten Prozess für ein schwieriges Integrationsproblem zusammengestellt.

Die Veröffentlichung beweist nicht, dass ein Agent sicher ist. Sie hilft einem Team, eine konkrete Sicherheitsbehauptung aufzustellen, Belege daran zu knüpfen und zu testen, ob eine Intervention ein definiertes Ergebnis verbessert hat.

Drei Signale werden zeigen, ob der Ansatz trägt

Der nächste Test besteht darin, ob unabhängige Teams die Fortschritte des Workflows reproduzieren, ohne nützliches Agent-Verhalten zu opfern oder versteckte Wartungslasten zu schaffen.

Das erste Signal ist die Replikation durch Dritte. Entwickler sollten öffentliche Evaluierungen beobachten, die Microsoft run-assert-eval auf Agenten außerhalb der mitgelieferten Beispiele anwenden.

Eine überzeugende Replikation würde die Risikodefinitionen, Fälle, Richtlinie, Traces, Richterkonfiguration und Ergebnisse der menschlichen Prüfung veröffentlichen. Sie würde auch Verstöße offenlegen, die nach der Governance verblieben.

Ergebnisse über verschiedene Modelle und Frameworks hinweg würden Microsofts Portabilitätsbehauptung stärken. Wesentliche Integrationsunterschiede würden offenlegen, wo ACS weiterhin von einzelnen Laufzeitumgebungen abhängt.

Das zweite Signal sind breitere Produktionsbelege. Teams müssen wissen, ob eingefrorene Evaluationen Vorfälle, Ablehnungen und Richtlinienumgehungen unter realem Traffic vorhersagen.

Nützliche Belege würden Trends bei Verstößen nach der Bereitstellung sowie von Kontrollen blockierte legitime Anfragen umfassen. Sie würden zudem Fehler verfolgen, die nach Änderungen an Modellen, Tools oder Prompts eingeführt wurden.

Die stärksten Bereitstellungen werden Evaluierungsartefakte mit kontinuierlichem Monitoring verbinden. Eine Verbesserung vor der Veröffentlichung ist bedeutsamer, wenn Produktions-Telemetrie dieselbe Verhaltensgrenze bestätigt.

Das dritte Signal ist die Reaktion des Projekts auf Umgehung und Richtliniendrift. Angreifer und gewöhnliche Nutzer können geschützte Aktionen über Wege erreichen, die in der ursprünglichen Suite fehlen.

Achten Sie auf neue Suiten zu indirekter Prompt-Injection, delegierter Autorität, widersprüchlichen Identitäten, Zustandsmanipulation und Multi-Agent-Übergaben. Beobachten Sie außerdem, wie das Projekt Überanpassung an eingefrorene Fälle verhindert.

Versionierte Richtlinien und Regressionstests werden wesentlich sein. Teams benötigen einen klaren Auslöser für die Wiederholung von Evaluationen, sobald sich Modelle, Tools, Berechtigungen oder Geschäftsregeln ändern.

Die Veröffentlichung sollte auch anhand ihrer Prüfungserfahrung beurteilt werden. Eine generierte Richtlinie ist nur nützlich, wenn Entwickler und Sicherheitsteams verstehen können, warum sie existiert und was sie blockiert.

Damit sind lokale Artefakte, zitierte Transkripte und eng definierte Verhaltensweisen mehr als Implementierungsdetails. Sie bilden die Beweiskette, die eine Genehmigung stützt.

Microsoft run-assert-eval ist daher am besten als eine als Skill verpackte Engineering-Disziplin zu verstehen. Sie verbindet Bedrohungsmodellierung, verhaltensspezifische Evaluation, Laufzeitdurchsetzung und kontrollierte erneute Tests.

Entwickler sollten nicht fragen, ob der Workflow einen gesamten Agenten als sicher zertifiziert. Sie sollten fragen, ob er ein wesentliches Risiko messbar macht, eine Kontrolle überprüfbar macht und eine Verbesserung reproduzierbar macht.

Das ist ein bescheideneres Versprechen als der Nachweis allgemeiner Sicherheit. Zugleich ist es ein glaubwürdigerer Ausgangspunkt für die Governance von Agenten.