Anthropic permet à ses clients d’héberger eux-mêmes Claude Managed Agents

Anthropic a lancé Claude Managed Agents en auto-hébergement le 12 novembre 2026, permettant aux clients d’exécuter l’ensemble du service et ses environnements isolés dans leur propre compte cloud ou dans un centre de données sur site. Les agents, les sessions et l’historique des sessions sont stockés sur cette infrastructure, tandis que les requêtes aux modèles peuvent être envoyées au fournisseur d’inférence choisi.

Les environnements isolés auto-hébergés proposés auparavant par Anthropic déplaçaient l’exécution des outils d’un agent vers les systèmes du client, tandis qu’Anthropic continuait à faire fonctionner l’agent. Les entrées et les sorties des outils transitaient toujours par Anthropic, qui stockait également les compétences et les espaces de stockage de mémoire. La nouvelle option étend le contrôle du client à l’API, à la boucle de l’agent et au stockage des sessions.

Ce que les clients exploitent désormais

L’architecture auto-hébergée s’articule autour de cma-server, qui fournit l’API Managed Agents, exécute la boucle de l’agent, stocke les agents, les sessions et leur historique, et appelle le fournisseur d’inférence configuré. Des processus de travail distincts exécutent les outils de terminal et de gestion des fichiers dans les environnements isolés des clients ; le serveur lui-même n’exécute jamais ces outils.

Le serveur exploité par le client expose la même API Managed Agents que le service hébergé d’Anthropic, à l’exception des différences de fonctionnalités documentées, de sorte que le SDK Claude et ant l’interface en ligne de commande peuvent s’y connecter. Un déploiement persistant nécessite PostgreSQL 16 ou une version ultérieure. Sans base de données, le serveur ne conserve les données qu’en mémoire, et un redémarrage les efface. Les clients doivent contacter leur équipe de compte Anthropic pour demander le téléchargement, puis installer eux-mêmes chaque version.

Choix du fournisseur d’inférence et limites de circulation des données

Par défaut, les appels aux modèles sont envoyés à l’API Claude. Les clients peuvent plutôt sélectionner Amazon Bedrock, Claude Models sur Google Cloud (géré par Google), Microsoft Foundry ou une passerelle de modèles qu’ils exploitent, via les paramètres du fournisseur du serveur. Les agents continuent de désigner les modèles au moyen de leurs identifiants d’API Claude ; le serveur les convertit pour les fournisseurs qui proposent ces modèles, ce qui permet d’utiliser une définition d’agent sans la modifier.

L’auto-hébergement du service ne suffit pas à maintenir le trafic lié aux modèles au sein du réseau du client. Chaque appel à un modèle transmet au fournisseur d’inférence sélectionné l’ensemble de la conversation jusqu’à ce moment, y compris les invites, les entrées des outils et leurs résultats. La documentation de sécurité précise que le serveur ne se connecte à Anthropic que si l’API Claude est le fournisseur choisi, et qu’Anthropic n’a pas d’accès à distance au serveur exploité par le client ni à son journal.

Migration et limites d’exploitation

Les instructions de migration précisent qu’aucune donnée n’est copiée depuis le service hébergé d’Anthropic, y compris l’historique des sessions. Les clients doivent recréer les agents, les compétences, les identifiants du coffre-fort et les espaces de stockage de mémoire sur leur propre serveur. Les organisations qui utilisent déjà des environnements isolés auto-hébergés peuvent connecter le même logiciel de processus de travail au nouveau serveur ; toutefois, les processus déclenchés par des webhooks ne fonctionneront pas, car le serveur auto-hébergé n’en envoie aucun.

Les clients assument également des responsabilités qui incombent à Anthropic pour le service hébergé : sécuriser le serveur, héberger les espaces de stockage de mémoire, détecter les utilisations inhabituelles et installer les nouvelles versions. Chaque déploiement dessert un seul locataire à un seul niveau de confiance. Des locataires distincts, ou des charges de travail présentant des niveaux de confiance différents, nécessitent donc des déploiements séparés, chacun disposant de sa propre base de données, de ses propres clés d’API de serveur et de ses propres processus de travail.

Certaines fonctionnalités du service hébergé ne sont pas disponibles, notamment les déploiements planifiés, les rêves et les webhooks. Les outils de recherche sur le Web et de récupération de pages Web restent désactivés tant qu’ils ne sont pas activés explicitement ; leur disponibilité dépend ensuite du fournisseur d’inférence. La recherche sur le Web est compatible avec l’API Claude, Claude Models sur Google Cloud (géré par Google) et Microsoft Foundry ; la récupération de pages Web est compatible avec l’API Claude et Microsoft Foundry.

La durée de conservation des sessions est également gérée par le client. Les sessions et leur historique restent dans la base de données du client jusqu’à leur suppression, plutôt que d’expirer au bout d’un certain temps. Leur suppression les retire de cette base de données, mais n’efface pas les copies présentes dans les sauvegardes, les journaux et traces exportés, les espaces de stockage de mémoire ou, dans Kubernetes, le volume de l’espace de travail de la session.

Pour les clients, la distinction essentielle est donc double : l’état de l’agent et son exécution peuvent rester au sein de leur propre déploiement, mais chaque conversation est toujours transmise au fournisseur d’inférence qu’ils sélectionnent. Ce contrôle accru implique de sécuriser et de mettre à jour le déploiement, d’isoler les locataires et d’accepter les lacunes par rapport aux fonctionnalités du service hébergé.