Am 10. September hat Anthropic zwei Dinge für Managed Agents nachgeliefert. Das eine ist eine dritte Berechtigungspolitik, das andere ein CLI-Befehl. Beides zielt auf dieselbe Frage: Wie behältst du die Kontrolle über einen Agenten, der stundenlang allein arbeitet?
Vorher gab es nur ganz oder gar nicht
Bisher kannte ein Toolset genau zwei Politiken. always_allow führt aus, ohne zu fragen. always_ask hält an und wartet. Standard ist always_allow für das Agent-Toolset und always_ask für MCP-Toolsets – verständlich, denn ein MCP-Server kann jederzeit ein neues Tool nachschieben.
Beides taugt nur für die Ränder. Wer alles freigibt, hat keine Kontrolle. Wer alles fragt, sitzt daneben und klickt.
Was auto macht
auto bewertet jeden Aufruf einzeln, und zwar auf dem Server. In die Bewertung gehen das Tool, die konkreten Eingaben und der bisherige Inhalt der Session ein. Derselbe Aufruf desselben Tools kann deshalb zweimal unterschiedlich ausgehen. Drei Ergebnisse sind möglich:
- Läuft. Hält der Server den Aufruf für sicher, passiert das Gleiche wie bei
always_allow. - Verweigert. Bewertet der Server den Aufruf als hochriskant, läuft das Tool nicht. Der Agent bekommt ein Fehler-Result mit
is_error: trueund dem Text, dass die Erlaubnis verweigert wurde. Die Session läuft weiter. Dein Client kann die Verweigerung nicht überstimmen. - Fragt nach. Kommt der Server zu keinem Schluss, hält die Session an wie bei
always_ask.
Eingeschaltet wird das mit permission_policy: {"type": "auto"}, an denselben zwei Stellen wie die anderen Politiken: im default_config eines Toolsets oder in einem configs-Eintrag für ein einzelnes Tool. Kein Toolset benutzt auto von sich aus. Das typische Muster dürfte sein: auto als Default, bash auf always_ask.
Sichtbar wird das Ganze im Event-Stream. agent.tool_use und agent.mcp_tool_use trugen schon immer evaluated_permission mit dem Ausgang der Prüfung – allow, ask oder deny. Neu ist ein evaluation-Objekt, das die Politik nennt, die zu diesem Ausgang geführt hat, und unter auto zusätzlich die Einschätzung des Servers samt reason_code, wenn gefragt oder verweigert wurde.
Der Absatz, den man lesen sollte
Anthropic schreibt selbst dazu, wie die Grenze verläuft, und das ist ungewöhnlich offen:
Was du in user.message-Events schreibst, gilt als deine Absicht – und kann den Server dazu bringen, einen Aufruf zu erlauben, den er sonst verweigern würde. Aus einem Tool-Result, einer abgerufenen Webseite, der Antwort eines MCP-Servers oder einer Nachricht zwischen Session-Threads liest der Server keine Absicht. Er bewertet diese Inhalte, nimmt aber keine Anweisungen daraus an.
Und dann der Satz, auf den es ankommt: Wer fremde Endnutzer-Eingaben in user.message-Events weitergibt, liefert sie dem Server als eigene Absicht. Ein Endnutzer kann sich damit einen Aufruf erlauben lassen. Anthropic sagt klar, was dagegen hilft: always_ask auf den Tools, die dieser Endnutzer nicht ohne Prüfung starten soll.
Dazu die zweite Warnung: auto ist kein menschlicher Prüfpunkt. Hält der Server einen Aufruf für sicher, läuft er, bevor jemand ihn gesehen hat, und die Folgen sind vielleicht nicht rückholbar.
Das ist keine Kleinigkeit. Wer auto als Ersatz für Aufsicht liest, hat eine Schicht Automatik eingebaut, die genau bei der Frage hilflos ist, für die man Aufsicht braucht.
Der zweite Teil: live an die Session
ant beta:sessions connect <session-id> hängt dein Terminal an eine laufende Managed-Agents-Session. Das Transkript lädt und läuft live mit, Tool-Aufrufe stehen mit Dauer und Ergebnis da, eine Statuszeile sagt, ob die Session läuft, idle ist oder auf deine Freigabe wartet.
Du kannst eingreifen: Enter schickt eine Nachricht, Esc unterbricht den Agenten, Ctrl+O klappt Tool-Eingaben, Ergebnisse und Token-Verbrauch auf. Wartet ein Aufruf auf Freigabe, wird die Eingabezeile zur Frage – Ja, Nein, oder Nein mit Begründung, die als deny_message beim Agenten landet. Ctrl+C löst dich wieder, die Session läuft weiter. Mit --web öffnet sich stattdessen der Session-Viewer der Console lokal im Browser. In Skripten nimmt man ant beta:sessions:events stream und send, weil connect ein interaktives Terminal braucht.
Einordnung
Der CLI-Befehl ist das, was gefehlt hat. Ein Agent, der lange läuft, ist ohne Blick ins Innere nicht zu betreiben, und ein Dashboard im Browser ist beim Debuggen die zweitbeste Lösung.
auto finde ich spannender und heikler. Die Idee ist richtig: Der Server sieht den Aufruf im Kontext und kann ihn deshalb besser beurteilen als eine statische Regelliste. Nur verschiebt das die Frage. Vorher hast du entschieden, welche Tools frei laufen. Jetzt entscheidet ein Modell über einzelne Aufrufe, und du entscheidest nur noch, wo du diesem Urteil traust. Dass Anthropic die Grenzen in die Dokumentation schreibt statt in ein Sternchen, spricht für sie. Gelesen werden muss es trotzdem.
Quellen: Claude Platform Release Notes, 10. September 2026, Permission policies, Connect to a Managed Agents session from your terminal