Microsoft macht Agenten-Sicherheit zum geschlossenen Prüfkreislauf

Microsoft veröffentlicht mit run-assert-eval einen Open-Source-Skill, der vier bislang oft getrennte Schritte verbindet: Risiken eines KI-Agenten entdecken, Fehler reproduzierbar messen, daraus eine Laufzeitregel erzeugen und dieselbe Evaluation erneut ausführen. Der entscheidende Punkt ist die Gegenprobe. Ein Sicherheitsfix gilt nicht deshalb als gut, weil er plausibel klingt, sondern weil er unter denselben Testbedingungen messbar wirkt.

Vom Risikokatalog zur überprüfbaren Korrektur

Der Skill kombiniert drei bereits veröffentlichte Bausteine. Clarity sucht nach möglichen Fehlermodi, ASSERT übersetzt ausgewählte Risiken in Evaluationen, und die Agent Control Specification beschreibt eine Laufzeitregel für den passenden Eingriffspunkt. Anschließend läuft die Evaluation noch einmal mit unveränderter Verhaltensdefinition, demselben Testset und demselben Bewertungsverfahren.

Das klingt nach Prozessdisziplin, ist aber technisch wichtig: Wenn ein Team nach dem Fix neue Fälle oder einen anderen Judge verwendet, vergleicht es zwei verschiedene Messungen. run-assert-eval hält diese Faktoren konstant. Nur die Policy soll sich ändern.

Das Beispiel zeigt Nutzen und Grenze

Microsoft demonstriert den Ablauf an einem Abrechnungsagenten, der Daten anderer Kunden offenlegte. In der Ausgangsmessung traten solche Verstöße in 12 von 40 anwendbaren Gesprächen auf, also in 30 Prozent. Eine deterministische Regel blockierte fremde Account-IDs vor dem Werkzeugaufruf und filterte sie zusätzlich danach. Im kontrollierten Lauf sank die beobachtete Quote auf 2 von 34 Fällen beziehungsweise 5,9 Prozent.

Das ist ein deutlicher Fortschritt, aber kein Beweis universeller Sicherheit. Die Stichproben sind klein, mehrere Test-Splits hatten weiterhin Verstöße, und Microsoft bewertet hier den eigenen Werkzeugverbund. Positiv ist, dass der Bericht die Restfehler offen ausweist und zulässiges Verhalten getrennt misst. Ein Agent, der pauschal alles verweigert, wäre schließlich nicht sicher, sondern unbrauchbar.

Praktisch relevant ist die Trennung von Urteil und Durchsetzung

Die erzeugte Policy greift an definierten Stellen des Agenten-Lebenszyklus ein. Im Beispiel entscheidet eine Rego-Regel deterministisch, ob eine Account-ID zum angemeldeten Kunden gehört. Das Sprachmodell beurteilt also nicht selbst, ob ein Zugriff verdächtig wirkt. Genau diese Trennung ist für produktive Agenten sinnvoll: Modelle können Risiken finden und Testfälle erzeugen, kritische Grenzen sollten aber möglichst in überprüfbaren Regeln enden.

Das ergänzt zwei bereits sichtbare Entwicklungen. GitHubs lokale Copilot-Sandbox begrenzt die Ausführung technisch, während OpenTelemetry Aktionen von Copilot-Agenten beobachtbar macht. run-assert-eval setzt davor und danach an: Es sucht konkrete Fehlermodi und prüft, ob eine neue Kontrolle den gemessenen Fehler tatsächlich reduziert.

So sollten Teams den Skill einordnen

• Mit einem klar abgegrenzten Agenten und einem kritischen Daten- oder Aktionsrisiko beginnen.
• Gefundene Risiken vor der Evaluation menschlich auswählen und präzisieren.
• Policy, Manifest und Eingriffspunkt vor dem kontrollierten Lauf prüfen.
• Sicherheits- und Nutzbarkeitsmetriken gemeinsam betrachten.
• Verbleibende Verstöße als nächste Iteration behandeln, nicht als Randnotiz.

Der Skill soll laut Microsoft künftig zu einem wiederholbaren Release-Gate ausgebaut werden. Schon jetzt liefert er einen brauchbaren Entwurf für Teams, die Agenten nicht nur beobachten, sondern Änderungen mit belastbarer Gegenprobe absichern wollen. Das ist auch die passende Ergänzung zu GitHubs lernendem Agentic Autofix: Erinnerung und Automatisierung werden erst dann vertrauenswürdig, wenn ihre Wirkung reproduzierbar geprüft und ihre Grenzen kontrolliert werden.

Die klare Einordnung: run-assert-eval ist kein automatischer Sicherheitsstempel. Der wertvolle Teil ist der geschlossene Prüfkreislauf aus Fund, Messung, deterministischer Kontrolle und identischer Gegenprobe. Genau so wird aus einer Sicherheitsbehauptung ein überprüfbarer Betriebsnachweis.

Quellen

• Microsoft Command Line: Introducing run-assert-eval, 24. September 2026
• GitHub: Responsible AI ASSERT
• GitHub: Microsoft Agent Governance Toolkit – Policy Engine

KI-Hinweis: Dieser Beitrag wurde mit KI-Unterstützung recherchiert und redaktionell geprüft.