Managed Agents: die Domainliste gehört ans Werkzeug, nicht in den Prompt

Claude
Agentic Engineering
Verification

Am 19. August steht in den Release Notes der Claude Platform ein Eintrag, der nach Konfigurationsdetail aussieht und einen Unterschied markiert, den ich für den wichtigsten in der Agentenarbeit halte. Sie können jetzt festlegen, welche Sites die Werkzeuge web_search und web_fetch eines Managed-Agents-Agenten überhaupt erreichen. Nicht als Satz im Systemprompt, sondern als Feld an der Werkzeugkonfiguration. Meine These dazu: Eine Regel, die nicht durchgesetzt wird, ist eine Bitte. Zwischen einer Leitplanke, die man dem Modell nennt, und einer, an der es scheitert, liegt der Unterschied zwischen Hoffnung und Architektur.

Was hat Anthropic geändert?

Sie setzen allowed_domains oder blocked_domains auf dem Eintrag des jeweiligen Werkzeugs im configs-Array des Toolsets agent_toolset_20260401. allowed_domains sind die einzigen Hosts, die das Werkzeug erreichen kann, blocked_domains die, die es nie erreicht. Jedes Werkzeug trägt seine eigene Liste, web_search und web_fetch können also unterschiedlich beschränkt sein. Ein gelisteter Eintrag deckt den Host und alle seine Subdomains ab.

Im selben Zug nimmt web_fetch das Feld max_content_tokens an, eine Obergrenze dafür, wie viel abgerufener Seiteninhalt in den Kontext wandert, und web_search nimmt user_location für lokalisierte Ergebnisse. Jeder configs-Eintrag wird über sein name-Feld identifiziert und über ein optionales type-Feld typisiert. Anfragen, die nur name, enabled und permission_policy mitgeben, laufen unverändert weiter. In den typisierten SDKs werden die Einträge zu einer Union mit einem Typ pro Werkzeug.

Was passiert, wenn der Agent eine gesperrte Adresse aufruft?

Er bekommt einen Fehler, keine Ermahnung. Ein web_fetch-Aufruf auf eine URL, die die Listen nicht erlauben, liefert dem Agenten ein Fehlerergebnis zurück: is_error: true auf dem agent.tool_result-Ereignis, im Inhalt der Fehlercode url_not_allowed. Bei web_search fallen Treffer, die die Listen nicht erlauben, aus den Ergebnissen heraus. Das ist der ganze Punkt. Der Agent muss die Regel nicht kennen, sich nicht an sie erinnern und sie nicht befolgen. Er läuft dagegen.

Warum mir dieser Unterschied wichtig ist, hat REDAgentBench vor einer Woche gezeigt: In der zustandsgeprüften Diagnosekohorte der Autoren hat der Agent in fast jedem fünften bestätigten Verstoß die betroffene Regel unmittelbar vorher selbst genannt. Wissen ist nicht Einhalten. Ein Filter am Werkzeug fragt gar nicht erst nach Einsicht.

Wann wird die Konfiguration geprüft?

Format- und Limitverstöße werden mit einem 400 invalid_request_error abgewiesen, wenn Sie einen Agenten anlegen oder aktualisieren, und ebenso, wenn eine Sitzung mit eigenem tools-Block angelegt oder aktualisiert wird. Die Meldung für einen Eintrag mit beiden Listen enthält Only one of allowed_domains or blocked_domains may be set. Bei einem Formatfehler nennt die Meldung die Liste und die nullbasierte Position des Eintrags. Abgewiesen werden auch drei Einstellungen, die von den Such- und Abrufanbietern abhängen: eine Domain in allowed_domains, auf die der Crawler von Anthropic nicht zugreifen darf, ein user_location.country, das der Suchanbieter nicht unterstützt, und eine timezone, die kein gültiger IANA-Name ist.

Die Sitzung prüft die Konfiguration ein zweites Mal, wenn sie das Werkzeug zum ersten Mal initialisiert. Ist eine vorher akzeptierte Einstellung dann nicht mehr gültig, meldet die Sitzung ein session.error-Ereignis und geht zurück auf idle, ohne es erneut zu versuchen. Sie korrigieren das über die Werkzeuge der Sitzung, ziehen den Agenten nach, damit neue Sitzungen richtig starten, und schicken dann eine neue user.message.

Was gilt in Sitzungen mit mehreren Agenten?

Dort greifen alle Listen gleichzeitig, die einen Thread betreffen: die eigenen, die des Agenten, der ihn aufgerufen hat, und die aktuellen des Koordinators. Erlaubnislisten werden geschnitten, Sperrlisten addiert. Ein Agent aus dem Roster kann damit enger machen, was ein Werkzeug erreicht, aber nie weiter. Haben die kombinierten Erlaubnislisten keine gemeinsame Domain, bleibt das Werkzeug verfügbar, jeder Aufruf scheitert aber mit url_not_allowed und dem Hinweis, dass keine Domain erlaubt ist. Die Werkzeugbeschreibung sagt dem Modell das auch.

Drei Feinheiten dazu. max_content_tokens und user_location werden nicht kombiniert, sondern der Reihe nach genommen: eigener Wert, sonst der des aufrufenden Agenten, sonst der des Koordinators. Ein Roster-Eintrag vom Typ self hat keine eigenen Web-Einstellungen und folgt dem Koordinator. Und der Prüfer in ergebnisgetriebenen Sitzungen läuft grundsätzlich ohne web_search und web_fetch, unabhängig von diesen Einstellungen. Die Listen einer wartenden Sitzung lassen sich ändern; sie gelten dann für den Rest der Sitzung.

Wo die Grenze selbst Grenzen hat

Die Regeln für die Listen sind eng, und das ist gut so, weil ein Filter mit unklarem Abgleich schlimmer ist als keiner. Pro Eintrag entweder Erlaubnis- oder Sperrliste, nie beides. Eine Liste hält 1 bis 64 Domains, jede 1 bis 255 Zeichen; eine leere Liste wird abgewiesen, für keine Einschränkung lassen Sie das Feld weg oder senden null. Einträge sind reine Hostnamen, ohne Schema, Port, Zugangsdaten oder Platzhalter: example.com, nicht https://example.com und nicht *.example.com. IP-Adressen werden in keiner Form angenommen, bloße Top-Level-Domains und einteilige Namen ebenso wenig, und localhost sowie Hosts auf .local, .internal, .localdomain oder .invalid werden abgelehnt.

Eine Stolperstelle, die in der Praxis Zeit kostet: example.com deckt docs.example.com ab, aber www.example.com deckt example.com nicht ab, weil www eine Subdomain wie jede andere ist. Tragen Sie die nackte Domain ein, wenn Sie beides meinen. Für web_fetch darf eine Domain keinen Pfad enthalten, für web_search ist ein Pfadsuffix wie example.com/blog erlaubt, das der Suchanbieter allerdings als URL-Muster behandelt und nicht als strenge Host-Regel.

Zwei Sätze aus der Dokumentation halte ich für die eigentliche Warnung. Erstens: Die networking-Einstellungen einer Umgebung regeln den ausgehenden Verkehr der Sandbox und wirken nicht auf web_search und web_fetch, weil diese Werkzeuge auf den Servern von Anthropic laufen, auch bei einer selbst gehosteten Sandbox. Zweitens: Die organisationsweiten Einstellungen für Websuche und Webabruf in der Console gelten der Messages API, nicht den Managed-Agents-Sitzungen. Wer seine Netzgrenze bisher an einer dieser beiden Stellen vermutet hat, hatte für Agenten keine.

Was heißt das für Ihre Agenten?

Setzen Sie die Grenze dorthin, wo der Aufruf passiert. Für einen Agenten, der recherchieren soll, ist eine Erlaubnisliste der ehrlichere Anfang als eine Sperrliste, denn eine Sperrliste schützt nur vor dem, was Sie schon kennen. Und rechnen Sie mit dem, was ein Domainfilter nicht leistet: Er entscheidet, welche Hosts erreichbar sind, nicht, was auf einer erlaubten Seite steht. Die Abnahme des Ergebnisses bleibt Ihre Aufgabe.

Das ist dieselbe Linie wie bei den Session-Budgets, die einen Lauf bei Erreichen der Obergrenze anhalten, und bei den Inference Hooks, die ein Veto vor der Inferenz einlegen: Verlässlichkeit entsteht nicht dadurch, dass das Modell sich erinnert, sondern dadurch, dass die Umgebung nicht mitmacht. Genau das meine ich mit Agentic Engineering. Die Verantwortung bleibt beim Menschen, der den Agenten konfiguriert hat, nur hat er jetzt eine Stelle, an der er sie ausüben kann.