Anthropic a poussé début septembre 2026 une bascule qui change la façon dont on écrit un agent Claude sérieux : le mode auto des Managed Agents. Concrètement, tu n'écris plus la boucle tool_use / tool_result côté client. Tu envoies une permission policy à l'ouverture de session, et le serveur d'Anthropic décide seul quels appels d'outils s'exécutent, lesquels sont refusés, lesquels doivent attendre une validation humaine. Si tu pilotes déjà des agents Claude en production, cette bascule mérite qu'on la regarde de près, parce qu'elle déplace la surface de sécurité et la logique de contrôle au niveau du serveur.
Fonctionnalité en beta, ajoutée aux Managed Agents le 10 septembre 2026. Rien de ce qui suit ne concerne le mode auto de Claude Code (produit distinct, malgré le nom proche). On parle bien ici du produit API pour agents hébergés côté Anthropic, dont les évolutions ont commencé en juillet 2026.
Ce que change le mode auto par rapport au contrôle client
En mode client classique, chaque appel d'outil émis par le modèle repart au SDK. Ton code inspecte le nom de l'outil, les arguments, décide d'exécuter ou pas, renvoie un tool_result, et Claude repart pour un tour. Sur un agent qui enchaîne 30 tool calls, tu payes ce round-trip 30 fois, plus la latence réseau, plus le coût de maintenir un client qui reste connecté au bon endroit.
En mode auto, tu déplaces cette décision côté Anthropic. À l'ouverture de session, tu fournis une permission_policy. Le serveur évalue chaque agent.tool_use et agent.mcp_tool_use selon cette policy et prend une décision parmi trois : exécuter, refuser, ou mettre la session en pause pour validation humaine. Les événements de session exposent un champ evaluated_permission (allow, ask, deny) et un objet evaluation qui nomme la policy appliquée et, quand c'est pertinent, un reason_code (high_risk pour un refus, indeterminate quand le serveur n'a pas su trancher).
Ce qu'on perd : la boucle explicite côté client, donc la capacité de logger, transformer ou enrichir chaque tool_result avant qu'il ne reparte vers le modèle. Ce qu'on gagne : moins d'aller-retour réseau, une policy centralisée qui vit ailleurs que dans le code de l'agent, et un point d'observation unique pour l'équipe sécurité.
Anatomie d'une permission policy qui filtre les appels d'outils
Une policy utile ne se contente pas d'allow/deny par nom d'outil. Elle regarde aussi les arguments de l'appel précis, parce que le même outil peut être bénin ou destructeur selon comment il est invoqué : Anthropic documente que deux appels au même outil peuvent être évalués différemment selon le contexte de la session jusqu'à ce point.
Anthropic n'a pas publié la syntaxe exacte de configuration d'une permission_policy personnalisée au moment de la rédaction : ce qui est confirmé, c'est le résultat observable de l'évaluation, pas le format d'entrée. Trois principes ressortent des événements exposés. D'abord, une évaluation qui aboutit à un refus porte un reason_code de high_risk, et une évaluation qui n'a pas pu trancher porte indeterminate : la policy n'est donc pas un simple allow/deny binaire par nom d'outil, elle raisonne sur un niveau de risque. Ensuite, ask ne bloque pas l'appel, il met la session en pause et attend une décision humaine, ce qui suppose que quelqu'un ou un système écoute vraiment ce signal (voir plus bas ant beta:sessions connect). Enfin, chaque évaluation regarde le contenu de la session jusqu'à ce point, pas seulement l'outil isolé : le même appel peut être jugé différemment selon ce qui a précédé dans la conversation.
Avant de généraliser une policy à un agent en production, teste-la sur des appels réels de ton cas d'usage et observe le taux de ask et de deny qu'elle produit : une policy trop permissive annule l'intérêt de la fonctionnalité, une policy trop stricte multiplie les pauses pour validation humaine et ralentit l'agent.
Superviser une session en direct avec ant beta:sessions connect
Pour la création de session Claude Managed Agents elle-même, l'endpoint documenté par Anthropic est POST /v1/sessions (voir la mise à jour de juillet 2026 sur ce même produit). Le mode auto s'active au niveau de la permission policy fournie à l'ouverture de cette session.
Le complément apporté le 10 septembre 2026 est côté supervision, pas côté création : le CLI ant ajoute la commande ant beta:sessions connect, qui attache ton terminal à une session Managed Agents en cours. Elle permet de suivre le déroulé en direct, d'envoyer des messages dans la session, et d'autoriser ou refuser en direct les appels d'outils en attente de validation. L'option --web sert localement la visionneuse de session de la Console Claude au lieu du terminal. C'est le pendant humain concret du mode auto : à garder sous la main dès qu'une policy peut renvoyer ask.
Côté événements, un appel refusé par la policy n'est pas une exception qui casse ton code, c'est un événement de session (agent.tool_use ou agent.mcp_tool_use) qui porte evaluated_permission: "deny". Le modèle voit ce refus dans la conversation et peut proposer un autre chemin. Ta boucle applicative doit donc écouter ces événements et pas seulement le message final du modèle.
Quand choisir auto, quand rester en manuel
| critère | mode auto | mode manuel (contrôle client) |
|---|---|---|
| tool calls par session | beaucoup, latence sensible | peu, latence tolérable |
| effets métiers des outils | lecture, recherche, transformation | facturation, envoi client, écriture prod |
| enrichissement des tool_results | pas de transformation nécessaire | parsing, redaction, logs métier |
| gouvernance | équipe sécurité veut une policy centrale | règles logées dans le code applicatif |
| orchestration multi-agents | agent isolé, boucle simple | arbitrage client entre plusieurs agents |
Pas de recette universelle. Un agent de recherche qui compile de la doc publique gagne à passer en auto : latence divisée, code applicatif plus court, policy qu'un DSI peut auditer. Un agent qui déclenche un remboursement Stripe ou envoie un mail à un client garde intérêt à rester en manuel, parce que tu voudras probablement passer chaque payload par un middleware qui vérifie l'idempotence, logue dans ton propre système, et rejette selon des règles métier qui ne tiennent pas dans une policy JSON.
À noter aussi : le mode auto retire une partie de l'observabilité fine sur les tool_results. Tu vois les décisions de la policy, mais pas systématiquement le contenu complet des réponses d'outils comme tu le verrais dans une boucle client où c'est ton code qui les manipule.
Sécurité et gouvernance : ce que le mode auto déplace
La policy devient l'unique rempart. Même sans connaître son format d'écriture exact, traite-la comme du code sensible : versioning, revue par une deuxième paire d'yeux, tests avec des appels connus avant de la faire évoluer en production. Une équipe qui modifie sa policy à la volée dans la Console sans historique se prépare à découvrir un jour qu'un réglage trop permissif ajouté pour débloquer un incident n'a jamais été retiré.
Deuxième point de vigilance : les outils MCP. Un serveur MCP qui expose une opération d'écriture (créer un contact CRM, envoyer un message Slack) doit être couvert explicitement par la policy, avec une granularité qui épouse celle des outils réellement exposés par le serveur plutôt qu'une règle large qui couvrirait tout le serveur par ricochet.
Sur le plan opérationnel, la bonne pratique est de suivre le taux d'appels en ask et en deny par outil dès les premières sessions en mode auto, pour repérer aussi bien une policy trop permissive qu'une policy si stricte qu'elle multiplie les pauses pour validation humaine et dégrade la trajectoire de l'agent. Anthropic n'a pas publié de détail vérifié sur un éventuel coût en tokens spécifique aux appels refusés par la policy : ne pas avancer de chiffre sur ce point tant qu'il n'est pas confirmé par une source officielle.
Le cas des outils MCP dans une policy
Cas courant : un agent qui combine des outils Anthropic natifs (web_fetch, code_execution) et un serveur MCP interne qui expose un CRM maison. Le principe reste le même que pour les outils natifs : chaque opération MCP (lecture d'une fiche, mise à jour d'une opportunité, suppression d'un contact) peut recevoir un traitement différent selon son niveau de risque réel, une lecture n'ayant pas vocation à être traitée comme une suppression. Ce niveau de finesse suppose que tu connaisses la surface exacte de ton serveur MCP, donc que tu maîtrises comment brancher un serveur MCP et documenter ses outils. Un serveur MCP tiers dont tu ne contrôles pas l'évolution mérite une vigilance particulière, parce qu'une nouvelle version peut ajouter des outils que ta policy n'a jamais anticipés.
Sur les architectures qui font tourner plusieurs agents en parallèle sur le même périmètre, la question de la coordination inter-agents se pose en plus de la policy de permission. Ce n'est pas ce que le mode auto résout : Anthropic a publié une étude sur les risques de coordination entre agents laissés sans consigne explicite. Si tu construis dans cette direction, notre pilier agents couvre les patterns d'orchestration et de communication entre sessions.
Passer à la pratique
Le mode auto n'est pas une case à cocher qu'on active partout. C'est un choix architectural : tu déplaces le contrôle des appels d'outils du code applicatif vers une policy déclarative évaluée côté serveur, avec les gains (latence, gouvernance) et les renoncements (moins de transformation fine) que ça implique. La bonne façon de démarrer : prendre un agent existant à faible risque métier, écrire sa policy, la versionner, la faire tourner une semaine avec logs des décisions, et décider ensuite si le pattern mérite d'être étendu.
Si tu veux un cadre pour construire et déployer des agents Claude en production avec ce niveau d'exigence, notre programme Piloter vos agents autonomes avec Ottho couvre cinq semaines de sessions live, de la conception de la policy jusqu'à la mise en ligne d'agents opérationnels.