Damit Agenten beim Programmieren und bei anderen Aufgaben möglichst produktiv sind, brauchen sie ein gesundes Maß an Autonomie. Das heißt, sie sollten eigenständig arbeiten, kreativ sein und Aufgaben erledigen können, ohne zu oft anzuhalten und um Erlaubnis zu bitten.

Größere Autonomie bringt jedoch Sicherheitsrisiken mit sich, wenn Agenten unbeabsichtigte Aktionen ausführen. Das gilt besonders für lokale Agenten, die oft in der Nähe von Dateien, Zugangsdaten, Umgebungsvariablen und MCP-Tools laufen und Zugriff auf Produktionssysteme haben.

Die naheliegende Antwort ist, den User vor jeder Aktion zu fragen. Doch wenn zu oft um Erlaubnis gebeten wird, entsteht ein eigenes Sicherheitsproblem. Nach genügend wiederholten Prompts lesen Menschen nicht mehr sorgfältig, und der Freigabeprozess verliert an Aussagekraft.

Diese Woche haben wir Auto-review eingeführt. Damit verhalten sich Entscheidungen rund um Agentenautonomie eher wie ein Regler als wie ein Schalter. Die Grundidee ist, dass sich ein Agent frei bewegen können sollte, wenn wenig auf dem Spiel steht, aber langsamer wird, wenn seine nächste Aktion eine wichtige Grenze überschreitet.

Mit einem spezialisierten Klassifikator-Agenten bestimmen wir, wo eine Aktion auf diesem Spektrum liegt, indem er Aktionen vor der Ausführung im Kontext überprüft. Dafür mussten wir unsere Intuition dazu, wie Agentenautonomie gesteuert werden sollte, in ein funktionierendes Modell aus Konsequenzen, Absicht und Feedback übersetzen, das wir am realen Verhalten von Agenten testen konnten.

#Risiken im Kontext beurteilen

Ob eine Agent-Aktion ein Risiko darstellt, hängt von der jeweiligen Situation ab. Derselbe Befehl kann in einem Workflow harmlos und in einem anderen inakzeptabel sein. Entscheidend ist das Zusammenspiel von Aktion, Benutzeranfrage und den Folgen einer Fehlentscheidung.

Diese Erkenntnis brachte uns dazu, einen Klassifikator-Agenten zu entwickeln, der die allgemeine Autonomie des Agenten steuern sollte. Wir wollten, dass es ein kleines Modell ist, damit es schnell und kostengünstig auszuführen bleibt und zugleich differenziert beurteilen kann, ob die nächste Aktion mit der Absicht des Benutzers konsistent ist.

Die zentrale Regel, die wir dem Klassifikator gaben, war, dass er nachsichtiger sein sollte, wenn weniger auf dem Spiel steht, und vorsichtiger, wenn mehr auf dem Spiel steht. Mit diesem grundlegenden Verständnis begannen wir, den Klassifikator als schnellen, kontextbezogenen Prüfer zu entwickeln, der direkt im Ausführungspfad des Agenten sitzen konnte.

#Den Klassifikator entwickeln

Die erste technische Entscheidung war die Modellwahl. Der Klassifikator läuft, bevor ein Tool-Aufruf ausgeführt wird, sitzt also direkt im Agent Loop und muss nicht nur präzise, sondern auch schnell sein. Dass wir mit mehreren Modellen arbeiten, hat hier geholfen, weil wir eine große Bandbreite an Modellen und Reasoning-Modi ausprobieren und dann das Modell auswählen konnten, das genau den richtigen Punkt zwischen Geschwindigkeit und Urteilsvermögen traf.

Eine frühe Überraschung war, dass Modelle mit weniger Reasoning nicht immer schneller waren. Wenn ein Modell Schwierigkeiten hatte, die Policy oder den Tool-Aufruf zu verstehen, konnte es am Ende mehr Zeit und Token darauf verwenden, nach einer Antwort zu suchen, die dann trotzdem schlechter ausfiel. Der bessere Kompromiss war ein kleines Modell mit genug Reasoning, um die Entscheidung sauber zu treffen.

Wir haben den Klassifikator außerdem agentenbasiert gemacht, weil manche Aktionen nicht allein anhand des Befehls beurteilt werden können. Ein Befehl wie python script.py kann sicher oder unsicher sein, je nachdem, was in der Datei steht. Deshalb kann der Klassifikator den Workspace mit Tools wie ReadFile, Grep, Glob und ListDir prüfen, bevor er entscheidet.

Wir haben einen separaten Klassifizierungs-Endpoint vermieden, weil ein zusätzlicher Roundtrip die Latenz direkt vor jedem überprüften Tool-Aufruf erhöhen würde. Stattdessen läuft der Klassifikator im selben RPC-Stream wie der übergeordnete Agent und verwendet eine Architektur, die Subagents ähnelt.

#Die Feedbackschleife gestalten

Die nächste Entscheidung war, wie sich eine Blockierung verhalten sollte. Wir wollten nicht, dass der Klassifikator zu einem weiteren Generator für Bestätigungsaufforderungen wird. Wenn er eine Aktion blockiert, gibt er dem übergeordneten Agenten eine Erklärung zurück, und der übergeordnete Agent kann dieses Feedback oft nutzen, um einen sichereren Weg zu wählen, ohne den Benutzer zu unterbrechen.

Die Absicht des Benutzers macht dieses Feedback nützlich. Die Frage ist nicht, ob eine Aktion für sich genommen riskant aussieht. Die Frage ist, ob sie durch das gerechtfertigt ist, was der Benutzer den Agenten tun lassen wollte. So kann normale Entwicklungsarbeit weiterlaufen, während Aktionen mit größeren Folgen ein klareres Signal vom Benutzer erfordern.

Dieses Design funktioniert nur, wenn der Klassifikator auf die Aktionen abgestimmt ist, die er durchlassen sollte, und auf diejenigen, die er stoppen sollte. Deshalb brauchten wir Evals, die beides abdeckten.

#Testen des Klassifikators

Unser erster Satz an Evals stammte aus internen Nutzungsdaten, mit denen wir die typische Form der Agent-Arbeit besser verstehen wollten. Der Klassifikator musste riskante Aktionen erkennen, ohne die routinemäßige Entwicklungsarbeit zu blockieren, und interne Sitzungen waren der beste Weg, diese Baseline sichtbar zu machen. Wir begannen mit ungefähr 12 Stunden interner Entwickler-Sitzungen, kürzten das dann und bereinigten häufige Aktionen um Duplikate, bis 6.122 gelabelte Zeilen übrig blieben.

Wir brauchten auch synthetische Daten, weil die schlimmsten Fälle in der normalen Nutzung nicht oft genug auftreten. Wir generierten Fälle, in denen der Agent möglicherweise Secrets ausliest, Produktionsdaten verändert, nicht vertrauenswürdigen Anweisungen folgt oder Aktionen mit großen Nebenwirkungen ausführt. Diese Beispiele verschafften uns Abdeckung für die Fehler, die der Klassifikator am dringendsten erkennen sollte.

Die Policy änderte sich, während wir dazulernten, was die Arbeit mit den Daten komplexer machte. Wenn wir die Verhaltenskategorien änderten, die der Klassifikator erkennen sollte, mussten wir das Eval-Set neu labeln oder neu erzeugen. Andernfalls würden wir den aktuellen Klassifikator gegen ein veraltetes Verständnis des Problems testen.

Wir führten die Evals durch dieselbe Backend-Klassifikator-Schleife aus, die auch in der Produktion verwendet wird. Dadurch konnten wir den gesamten Ablauf testen, einschließlich Tool-Nutzung, endgültiger Klassifizierung, Modell-Overrides und Parse-Fehlern. Die Evals prüften die endgültige Entscheidung zum Erlauben oder Blockieren zusammen mit dem Kontext, den der Klassifikator verwendete, wenn er vor einer Entscheidung den Workspace untersuchen musste.

Wir suchten außerdem nach Flapping. Wenn derselbe Fall sechsmal erlaubt und viermal blockiert wurde, bedeutete das normalerweise, dass die Policy oder der Prompt nicht präzise genug formuliert war. Wiederholte Durchläufe gaben uns eine Möglichkeit, diese instabilen Fälle zu finden und den Klassifikator so lange zu schärfen, bis sein Verhalten konsistenter war.

#Vollständige Blockierungen minimieren

In der Praxis muss nur ein kleiner Teil der Aktionen des Agenten vom Klassifikator überprüft werden. Viele Befehle sind bereits durch Allowlists oder Sandboxing abgedeckt, sodass der Klassifikator meist nur dann zum Einsatz kommt, wenn für die Aktion eine kontextbezogene Bewertung nötig ist.

Wenn der Klassifikator zum Einsatz kommt, blockiert er derzeit rund 4 % der Aktionen, wobei eine Blockierung nicht sofort zu einer Benutzerabfrage führt. Der Klassifikator sendet stattdessen eine Erklärung an den übergeordneten Agenten zurück, der die Aktion oft eingrenzen, ein anderes Tool auswählen oder den riskanten Schritt ganz vermeiden kann.

Einige Blockierungen durch den Klassifikator führen zu Unterbrechungen für den Benutzer, aber insgesamt sehen wir, dass nur etwa 7 % aller Chats im Auto-review-Modus zu mindestens einer Unterbrechung führen. Zum Vergleich: Einige Enterprise-Kunden, mit denen wir zusammenarbeiten, hatten zuvor in ihrer Organisation ungefähr 40 % blockierte Aktionen.

Diese ersten Daten sind konsistent mit dem zentralen Produktverhalten, das wir erreichen wollten. Der Klassifikator unterbricht den Benutzer nur selten direkt, und in den meisten blockierten Fällen kann der übergeordnete Agent das Feedback nutzen, um auf sicherere und stärker eingegrenzte Weise fortzufahren.

#Feinabstimmung der Agentenautonomie

Auto-review steckt noch in den Anfängen, und unser Verständnis des Autonomiespektrums wird sich weiterentwickeln, je leistungsfähiger Agenten werden. Heute konzentriert es sich auf lokale Agenten in der Desktop-App, und wir erwarten, dass dieselben Ideen mit der Zeit auch bestimmen werden, wie wir die Agentenautonomie an anderen Stellen steuern.

Wir möchten, dass Agenten echte Autonomie haben, während die Entscheidung, sie auszubremsen, vom Kontext abhängt statt von einer einzigen globalen Einstellung. Der Klassifikator hilft uns, die Sicherheit zu verbessern, ohne Autonomie wieder in eine Flut von Bestätigungsaufforderungen zu verwandeln. Er erkennt Aktionen, die genauer geprüft werden müssen, gibt dem übergeordneten Agenten Feedback und lässt den Agenten weiterarbeiten, wenn es einen sichereren Weg gibt.

Auto-review ist jetzt der Standard für neue Benutzer. Bestehende Benutzer können es unter Einstellungen > Agenten aktivieren.