Claude Managed Agents web_fetch: Eine URL muss jetzt vom Nutzer oder aus dem Web kommen

Seit dem 7. Oktober ruft das Tool web_fetch in Claude Managed Agents nur noch eine URL ab, die in der Session bereits aufgetaucht ist. Die Release Note nennt Beispiele für solche Quellen und den Grund:

the web_fetch tool now fetches only URLs that have already appeared in the
session, for example in the text of a user message, in a web_search result,
or in a page that web_fetch returned earlier. This reduces the risk of data
exfiltration.

Dieselbe Release Note sagt auch, was nicht zählt: eine URL, die nur in Claudes eigener Ausgabe steht, in den Systemanweisungen des Agenten, in einem angehängten Dokument oder in der Ausgabe von bash, read oder einem MCP-Tool. Wer eine solche URL abruft, bekommt den Fehler url_not_in_prior_context. Willst du dem Agenten absichtlich eine URL geben, schreib sie in den Text einer user.message.

Meine Lesart: Wichtiger als die Regel ist, was sie unangetastet lässt. In einer Umgebung, die mit den API-Standardwerten angelegt wurde, lässt sich die abgelehnte URL weiterhin mit einem einzigen Shell-Befehl abrufen.

Was blockiert die web_fetch-Regel in Claude Managed Agents tatsächlich?

Sie blockiert den simpelsten Exfiltrationsweg, der einem per Injection gekaperten Agenten offensteht: ein Geheimnis in eine URL schreiben und sie abrufen. Eine Anweisung, die in einer Datei oder auf einer Seite platziert wurde, kann https://collector.example/?k=<your key> nicht mehr über web_fetch nach außen schicken, solange keine externe Quelle diese URL je gezeigt hat. Der Angreifer kann einen Link auf eine Seite schreiben, kennt aber deinen Key nicht im Voraus, um ihn dort einzusetzen. Die Release Note sagt nicht, ob die vollständige URL abgeglichen wird oder nur ein Teil davon. Der Schutz funktioniert aber nur, wenn es die vollständige URL ist.

Warum zählt in Managed Agents eine Webseite als vorheriger Kontext, die bash-Ausgabe aber nicht?

Mit Vertrauen hat das nichts zu tun. Eine abgerufene Seite gehört zum am wenigsten vertrauenswürdigen Text einer Session, und sie zählt. Deine bash-Ausgabe entsteht in der Sandbox durch ein Tool, das du selbst aktiviert hast, und sie zählt nicht. Nach meiner Lesart verläuft die Grenze dort, wo das Modell den Kanal steuern kann. In Managed Agents macht das Modell die Aufrufe von bash, read und MCP selbst innerhalb der Session. Würde deren Ausgabe zählen, könnte ein einziges echo jede URL, die Claude sich ausdenkt, in „Tool-Ausgabe“ verwandeln, und die Regel wäre wirkungslos. Ein Suchergebnis oder eine abgerufene Seite kommt von außen und ist bereits fertig geschrieben. Systemanweisungen und angehängte Dokumente sind ebenfalls ausgeschlossen, obwohl das Modell sie nicht schreiben kann. Im Zweifel lehnt die Regel also eher ab.

Die Prüfung in der Messages API passt zu dieser Lesart. Dort zählen Ergebnisse deiner clientseitigen Tools als vorheriger Kontext, "even when they echo text that Claude produced", weil dein Code das Tool ausgeführt und das Ergebnis zugelassen hat. Serverseitige Tools wie Code Execution und der MCP Connector zählen nicht. Managed Agents betreibt die Sandbox für dich, deshalb zählt bash dort als serverseitiges Tool. Die Vertrauensordnung wirkt verdreht, denn eine Webseite steht über deinen eigenen Tools. Aber die Entscheidung ist von der Art, für die ich im Essay über Konnektoren argumentiert habe: Sie richtet sich nach dem Kanal, über den ein Text hereinkam und den der Harness kennt, nicht nach dem Inhalt des Textes.

Was hat sich am selben Tag beim Limited Networking von Claude Managed Agents geändert?

Am selben Tag kamen zwei weitere Einträge hinzu. Eine Cloud-Umgebung mit limited Networking wendet ihre allowed_hosts jetzt auch auf web_search und web_fetch an, und ohne eingetragene Hosts liefert keines der beiden Tools eine Seite oder ein Ergebnis. Eine Session anzulegen oder zu aktualisieren scheitert jetzt mit HTTP 400, wenn allowed_domains eines aktivierten Web-Tools einen Eintrag außerhalb von allowed_hosts enthält. Die Listen werden unterschiedlich abgeglichen: Ein Tool-Eintrag deckt Subdomains ab, ein allowed_hosts-Eintrag ist genau ein Host, außer er beginnt mit *.. ["example.com"] deckt docs.example.com also nicht ab.

Der Nebeneffekt ist der Teil, den du einplanen solltest. Laut den Environment-Docs ist ein Host, den du für die Web-Tools zu allowed_hosts hinzufügst, "also open to the sandbox", und der Zugriff gilt "per host, not per operation", Uploads eingeschlossen. Jeder Host, den du unter limited zum Lesen für deinen Agenten freigibst, ist auch ein Ziel, an das er per curl Daten senden kann.

Welche Wege aus einer Claude-Managed-Agents-Session bleiben nach dieser Änderung offen?

bash, wenn du es zulässt. Eine Umgebung, die über die API ohne networking-Feld angelegt wird, bekommt unrestricted, und die Standard-Permission-Policy des Agent-Toolsets ist always_allow. Mit diesen Defaults lässt sich eine URL, die nur an der Prior-Context-Prüfung scheitert, weiterhin aus der Shell abrufen, und nichts hält das auf außer einer allgemeinen Sicherheits-Blocklist. Die neue Regel schließt eine Tür in einem offenen Gebäude. Das Muster ist nicht neu: In OpenAIs Misalignment-Berichten lehnten die Browser-Tools URLs ab, während Uploads über die Shell durchkamen.

Zwei Lücken bleiben selbst bei gesperrtem Netzwerk. Eine Seite, die der Agent abgerufen hat, kann viele vorbereitete Links enthalten, und welchem er folgt, ist selbst ein Signal. Ist das Ziel erlaubt und sieht der Angreifer die Anfragen dorthin, kann jede abgerufene Seite die nächste Runde Links liefern. Dieser Kanal ist langsam, hat aber keine Obergrenze. Das ist meine Lesart, die Docs gehen nicht darauf ein. Und einer user.message wird ungeprüft vertraut: Wenn deine App Text von Endnutzern dorthin weiterreicht, besteht jede darin enthaltene URL die Prior-Context-Prüfung. Nur die Domain-Listen greifen dann noch. Die Permission-Policy auto wertet user.message ebenfalls als deine Absicht. Das ist ein automatisiertes Urteil, keine Prüfung, und es gilt dieselbe Vorsicht wie beim Approval-Klassifikator von Claude Code.

Ein paar Dinge lassen die Docs offen. Die Messages API lehnt eine URL ab, die offenbar ein Credential enthält, das weder in den Systemanweisungen noch im Text des Nutzers steht. Ob diese Prüfung auch in Managed Agents greift, sagt die Release Note nicht. Ebenso wenig sagt sie, in welche Kategorie Ergebnisse von Custom Tools fallen. Dabei kommen sie wie Client-Tools in der Messages API von deinem Code zurück.

Wie konfigurierst du eine Claude-Managed-Agents-Umgebung am ersten Tag?

Setz networking jedes Mal ausdrücklich auf limited und trag nur die Hosts ein, die der Job braucht. Liest der Agent nur im Web, deaktiviere bash, damit die gemeinsame Host-Liste keiner Shell etwas öffnet. Braucht er eine, stell bash auf always_ask. auto hält zwar manchmal an, und das ist besser als nie. Vor einem erlaubten Aufruf schaut aber niemand hin. Gib die URLs, die abgerufen werden sollen, in einer user.message mit. Das ist jetzt der dokumentierte Weg hinein. Halte nicht vertrauenswürdigen Nutzertext dort heraus, es sei denn, du willst ihm denselben Status geben. Die Regel legt fest, welche URLs das Modell nicht tippen darf. Wer oder was sonst in der Sandbox URLs eintippen kann, regelt sie nicht.