Anthropic décline Claude Managed Agents en cloud privé et sur site
Sans les laisser installer ses LLM, le fournisseur propose aux entreprises de déployer sa plateforme d’exécution d’agents IA sur leurs instances de cloud privé ou sur site. Ce niveau de contrôle supplémentaire sur l’architecture se paie par davantage de responsabilités en matière de cybersécurité.
Le 12 novembre, le fournisseur de LLM, après avoir lancé Fable 5.2, a dévoilé la beta privée de Claude Managed Agents. Il s’agit tout simplement d’un moyen pour ses clients de déployer des agents IA dans leur propre environnement, en cloud ou sur site.
Claude Managed Agents (CMA) existait déjà comme un service managé pour faciliter le déploiement d’agents IA. Il était également possible d’exécuter les outils sur la machine du développeur. Là, les entreprises peuvent s’appuyer sur le framework d’Anthropic, mais maintenir le contrôle sur les agents IA et son orchestrateur.
Plus de contrôle…
« Avec les Managed Agents autohébergés, tous les composants du service s’exécutent dans votre propre cloud ou sur site, y compris le harnais, les environnements de test, les identifiants et l’historique des sessions », précisent les porte-parole du fournisseur. « Vous gérez le serveur Managed Agents, sa base de données et les nœuds de travail sur lesquels les agents exécutent leur shell et leurs outils de gestion de fichiers ».
La conservation des sessions – et donc du contexte – réclame une base de données PostgreSQL 16 ou supérieure.
Le serveur Managed Agents sert d’ordonnanceur. Il gère l’API, la boucle agentique, le stockage des agents, des sessions et de leur historique, mais il n’exécute pas lui-même les outils. Cette partie est confiée à des sandboxes, qui prennent en charge le shell et les outils fichiers des agents.
Depuis un client applicatif, il convient d’abord de créer une session qui pointe vers le serveur Claude Managed Agents. Elle est placée dans une file d’attente. Le worker s’occupe de l’élément à exécuter en s’appuyant sur les skills et l’historique de la session. Le modèle peut être appelé depuis la plateforme d’Anthropic ou celle d’AWS, GCP ou Azure, voire une passerelle interne.
Les entrées et les sorties des outils sont traitées par les workers, puis renvoyées au serveur qui lui-même les passe au modèle.
Anthropic insiste sur la séparation entre les sandbox, l’historique de session et les coffres-forts où résident les clés. Pour les appels aux outils MCP et aux API, un service proxy ajoute les identifiants à la requête et les secrets peuvent être stockés dans un gestionnaire déployé par l’entreprise.
Sur site, Anthropic prend en charge HashiCorp Vault. Dans le cloud, Azure Key Vault et les gestionnaires de secrets d’AWS et de Google Cloud sont également référencés. Les sessions de chaque utilisateur peuvent être chiffrées.
Kubernetes et gVisor : une certaine proximité technique avec Google
À la manière de ce que propose Nvidia avec Openshell, il est possible de restreindre les requêtes sortantes de la sandbox. Le control Plane Managed Agents collecte la télémétrie (les event log) et l’exporte éventuellement vers une plateforme compatible avec OpenTelemetry.
Dans sa documentation générale, Anthropic se veut le plus agnostique possible. Les sandbox peuvent s’appuyer sur des espaces de travail isolés, des conteneurs, des VM ou encore des microVM. Le fournisseur recommande de privilégier les environnements éphémères. Des éditeurs et des fournisseurs, dont Vercel, AWS, Google, ou encore Cloudflare proposent des guides d’implémentation.
En test, Anthropic propose une pile Docker Compose rassemblant le serveur CMA, la base de données PostgreSQL et les workers dans leurs sandbox.
En production, il décline deux Helm Charts pour déployer la plateforme sur Kubernetes. La base de données est séparée. L’implémentation de référence s’appuie sur la version 1.30 de K8S, le contrôleur Agent Sandbox et les nœuds gVisor, un framework qui isole les applications de l’OS Linux. Cette technologie développée par Google est la base d’Agent Substrate, la sandbox que le géant du cloud a confié à la CNCF.
Dans la configuration actuelle de CMA, le serveur attribue à chaque session son pod de sandbox.
… Et plus de responsabilités pour les clients
Anthropic offre beaucoup de contrôle aux clients, mais c’est à eux de gérer la qualité des images de sandbox basé sur Linux et la sécurité de leur runtime. Ils doivent aussi restreindre le trafic aux outils utilisés, s’assurer de la bonne rotation des clés de chiffrement pour les sessions et les appels d’outils, au besoin l’isolement du code généré, ainsi que gérer la rétention des logs d’outils et des sessions.
À noter que sans action de la part des administrateurs, Anthropic et les hyperscalers qui hébergent ses modèles récupèrent un bon nombre d’informations. « Pour chaque appel au modèle, le serveur envoie la conversation jusqu’à ce point, y compris les entrées et les résultats des outils, à votre fournisseur d’inférence », lit-on dans la documentation. « Par défaut, il s’agit de l’API Claude. Un appel à l’API Claude transmet également les identifiants de sa session ainsi que ceux de l’agent et de l’environnement de cette session ». Anthropic précise toutefois que Claude Managed Agents Self Hosted est compatible avec sa politique Zero Data Retention et « Anthropic n’a aucun accès distant » au contenu des sessions.
Le fournisseur s’est déjà engagé dans la sécurisation des charges de travail agentique. En amont de son introduction en bourse, il se doit de proposer une feuille de route pertinente pour les entreprises régulées.
Au mois d’octobre, Anthropic a discrètement réalisé l’acqui-hiring des équipes d’Opaque, une société spécialisée dans l’informatique confidentielle dédiée à l’IA. L’idée semble de poursuivre le développement de Claude Managed Agents afin de renforcer la protection des données, des exécutions et des modèles eux-mêmes.
Avant cela, le fournisseur devra combler les écarts de fonctionnalités entre sa version de CMA et celle autohébergée. Certains webhooks, les déploiements planifiés, l’API Files, les skills préintégrés et l’actualisation automatique d’OAuth pour les serveurs MCP ne sont pas pris en charge. Les solutions de contournement ne sont pas entièrement satisfaisantes.
