--- title: Données et accès dans Claude Managed Agents auto-hébergé url: https://platform.claude.com/docs/fr/managed-agents/self-hosted-data-and-access description: Ce que Claude Managed Agents auto-hébergé envoie en dehors de votre réseau, où vont son journal, ses traces et ses métriques, combien de temps les données sont conservées, qui peut atteindre le serveur et comment séparer les locataires. --- Pour demander l’accès à Claude Managed Agents auto-hébergé, contactez l’équipe de votre compte Anthropic. Avec [Claude Managed Agents auto-hébergé](https://platform.claude.com/docs/fr/managed-agents/self-hosted), vous exploitez le serveur, sa base de données et les sandboxes dans lesquelles les « workers » (processus de travail) exécutent les outils de shell et de fichiers de l’agent. Cette page répond aux questions d’un examen de sécurité. Le fournisseur d’inférence du serveur est le service qui répond à ses appels au modèle. Le serveur se connecte à Anthropic uniquement lorsque ce fournisseur est l’API Claude. Anthropic n’a aucun accès à distance au serveur ni à son journal. ## Ce qui quitte votre réseau ### Chaque connexion établie par le serveur Le serveur se connecte uniquement aux destinations suivantes : * Votre fournisseur d’inférence * La base de données du serveur * Les services qui émettent les identifiants du serveur pour les appels au modèle, s’il obtient ces identifiants auprès d’un service * Le service de listage des modèles d’un fournisseur cloud, si votre fournisseur d’inférence liste ses modèles sur un service distinct * Les serveurs MCP que vous autorisez * Les hôtes Git que vous autorisez, pour les dépôts qu’utilisent les sessions * Un collecteur OpenTelemetry, si vous en configurez un * Les fournisseurs d’identité que vous indiquez pour l’authentification unique, si vous en configurez * Un gestionnaire de secrets ou un service de gestion des clés, si vous en configurez un * Les services qui émettent les identifiants du serveur pour ce gestionnaire de secrets ou ce service de gestion des clés * Tout autre service que le serveur appelle parce que vous l’avez configuré pour cela Le fournisseur d’inférence par défaut est l’API Claude. Si vous configurez un autre fournisseur d’inférence, les appels au modèle y sont adressés à la place. Le serveur se connecte à Anthropic uniquement lorsque l’API Claude est son fournisseur d’inférence. Lorsque le fournisseur d’inférence propose les outils de recherche web et de récupération web, c’est lui qui les exécute. Le serveur n’établit aucune connexion propre pour ceux-ci. Les outils sont désactivés tant que vous ne les activez pas dans les paramètres du serveur. Pour vérifier le trafic du serveur, comparez le journal de votre proxy de sortie ou de votre pare-feu avec cette liste. Les requêtes du serveur vers l’API Claude portent un en-tête `User-Agent`. Consultez [Champs qui nomment le logiciel serveur](https://platform.claude.com/docs/fr/managed-agents/self-hosted-data-and-access#fields-that-name-the-server-software). ### Ce que les workers peuvent atteindre La liste des destinations ne couvre que le serveur. La [passerelle de sortie](https://platform.claude.com/docs/fr/managed-agents/self-hosted/agent-identity#environment-variable-credentials), si vous l’exécutez, se connecte aux hôtes que vous lui indiquez et leur envoie les valeurs d’identifiants que vous stockez pour eux. Les workers sont distincts. Un worker dispose de l’accès réseau que vous accordez au conteneur, à la VM ou à tout autre bac à sable dans lequel il s’exécute. Chaque commande qu’un agent exécute par l’intermédiaire du worker dispose du même accès réseau. ### Ce que le serveur envoie à son fournisseur d’inférence Chaque appel au modèle contient la conversation jusqu’à ce point, y compris les prompts, les entrées d’outils et les résultats d’outils. Lorsque l’API Claude est le fournisseur d’inférence, chaque appel au modèle porte également jusqu’à trois en-têtes. Ils contiennent des identifiants générés par votre serveur : | En-tête | Ce qu’il contient | | ----------------------------------------- | ------------------------------------------------- | | `anthropic-managed-agents-session-id` | L’identifiant de la session que l’appel sert | | `anthropic-managed-agents-agent-id` | L’identifiant de l’agent de cette session | | `anthropic-managed-agents-environment-id` | L’identifiant de l’environnement de cette session | Un identifiant ne contient aucun nom ni aucun contenu, mais il encode l’heure à laquelle votre serveur l’a créé. Grâce à ces en-têtes, Anthropic peut attribuer l’utilisation à une session, à un agent ou à un environnement. Aucun paramètre ne permet de les désactiver. Si `ANTHROPIC_BASE_URL` désigne un proxy ou une passerelle, les en-têtes y sont envoyés. Avec tout autre fournisseur d’inférence, le serveur ne les envoie jamais. Lorsque l’API Claude est le fournisseur d’inférence, le serveur vérifie également auprès de l’API Claude que ses identifiants pour les appels au modèle sont valides. Il effectue cette vérification au démarrage, puis toutes les 60 secondes, sauf si vous modifiez `health.check_interval`. Ces vérifications n’exécutent aucune inférence et ne portent aucun des trois en-têtes. ### Champs qui nomment le logiciel serveur Chaque requête adressée à l’API Claude comporte un en-tête `User-Agent` qui indique le logiciel serveur et sa version. L’en-tête lui-même n’identifie pas votre déploiement. Comme pour toute requête adressée à l’API Claude, la clé API identifie votre organisation. Anthropic peut utiliser cet en-tête pour comptabiliser l’utilisation de Managed Agents auto-hébergé. Les appels au modèle peuvent également porter l’étiquette `cma-server`, dans le corps de la requête sous la forme `metadata.user_id`. L’étiquette est la même sur chaque serveur ; l’étiquette elle-même n’identifie donc ni votre déploiement, ni vos utilisateurs, ni vos sessions. Lorsqu’un appel atteint Anthropic, Anthropic peut utiliser l’étiquette pour comptabiliser l’utilisation de Managed Agents auto-hébergé, même si un proxy a supprimé l’en-tête `User-Agent`. Le fait qu’un appel porte l’étiquette dépend de sa destination : * **Le serveur envoie l’étiquette sur ces appels :** les appels adressés à l’API Claude, à Microsoft Foundry et à une passerelle de modèles qui accepte les mêmes requêtes que l’API Claude. * **Le serveur n’envoie jamais `metadata.user_id` sur ces appels :** les appels adressés à Amazon Bedrock, à Claude Models on Google Cloud (Google managed) et à une passerelle de modèles qui utilise un autre format de requête. Si une passerelle de modèles ou un proxy transmet un appel à un autre fournisseur, `metadata.user_id` peut l’accompagner. Sur les appels qui portent `metadata.user_id`, un proxy ou une passerelle qui vous appartient doit l’accepter dans le corps de la requête. S’il rejette ce champ, chaque appel au modèle échoue. ## Où vont le journal, les traces et les métriques Le serveur écrit son journal sur la sortie d’erreur standard. Lorsque vous exécutez le serveur sous Docker, Kubernetes ou un gestionnaire de services, ce système collecte le journal depuis la sortie d’erreur standard. Le serveur n’enregistre aucune trace ni aucune métrique tant que vous ne les activez pas avec les variables d’environnement OpenTelemetry standard. Il les envoie uniquement là où ces variables pointent. Un point de terminaison Prometheus peut également exposer des métriques. Consultez [Où le serveur écoute](https://platform.claude.com/docs/fr/managed-agents/self-hosted-data-and-access#where-the-server-listens). ## Combien de temps les données sont conservées Votre pipeline de journaux, votre collecteur et votre backend de traçage déterminent la durée de conservation du journal, des traces et des métriques. Le serveur ne conserve aucun fichier de journal et ne stocke ni traces ni métriques. Le serveur stocke tout le reste, comme les agents, les sessions et l’historique des sessions, dans votre base de données. Si vous ne configurez aucune base de données, ce qui est le cas par défaut, le serveur conserve ces données en mémoire, et un redémarrage les efface. Si vous configurez un gestionnaire de secrets, le serveur y conserve le secret de chaque nouvel [identifiant de coffre](https://platform.claude.com/docs/fr/managed-agents/vaults) au lieu de le conserver dans la base de données. Les secrets qu’il a stockés auparavant restent dans la base de données. Les sessions et leur historique restent dans votre base de données jusqu’à ce que vous les supprimiez. Le serveur ne supprime pas une session en raison de son ancienneté, qu’elle soit archivée ou non. La suppression d’une session via l’API retire la session et son historique de votre base de données, bien que le serveur conserve l’identifiant de la session. Le serveur peut refuser la suppression tant qu’une session est en cours d’exécution. La suppression n’atteint pas les copies situées ailleurs, comme les sauvegardes de base de données, les journaux et traces exportés, ou ce que l’agent a écrit dans un [magasin de mémoire](https://platform.claude.com/docs/fr/managed-agents/memory). Sur Kubernetes, la suppression laisse également en place le volume `/workspace` de la session, comme le décrit [Libérer le volume d’une session](https://platform.claude.com/docs/fr/managed-agents/self-hosted/kubernetes#free-a-sessions-volume). Ce que le serveur envoie au modèle, et ce que le modèle renvoie, relèvent de l’accord de votre organisation avec le fournisseur qui sert le modèle. Les conditions de conservation des données de cet accord s’appliquent. Lorsque l’API Claude sert le modèle, l’accord et les paramètres de conservation des données que votre organisation a conclus avec Anthropic s’appliquent. Si votre organisation dispose d’un dispositif de [conservation zéro des données (ZDR)](https://platform.claude.com/docs/fr/manage-claude/api-and-data-retention#zero-data-retention-zdr-scope), il couvre ces appels au modèle de la même manière que les autres appels à l’API Messages. La page « API et conservation des données » répertorie Claude Managed Agents comme [non couvert par la ZDR](https://platform.claude.com/docs/fr/manage-claude/api-and-data-retention#what-zdr-does-not-cover). C’est parce que lorsqu’Anthropic exploite le service, elle stocke les transcriptions de sessions jusqu’à ce que vous les supprimiez. Qui stocke les transcriptions dépend de qui exploite le service : * **Anthropic l’exploite :** Anthropic les stocke. Avec les [sandboxes auto-hébergées](https://platform.claude.com/docs/fr/managed-agents/self-hosted-sandboxes), vous n’hébergez que les sandboxes, et Anthropic exploite le reste. * **Vous l’exploitez, avec Managed Agents auto-hébergé :** Vous stockez vous-même les transcriptions. ## Qui peut atteindre le serveur Anthropic n’a aucun accès à distance au serveur ni à son journal. Vos applications et vos workers se connectent au serveur. Le serveur ne se connecte jamais à un worker. ### Identifiants acceptés par le serveur Anthropic n’émet aucun des identifiants que le serveur accepte, et n’en détient aucun. Chaque identifiant que le serveur accepte est l’un des suivants : * Un identifiant que vous avez défini ou créé * Un identifiant émis par votre fournisseur d’identité * Un identifiant que le serveur a lui-même généré, comme le jeton qu’il remet à un worker avec chaque tâche ### Où le serveur écoute Le serveur accepte les requêtes API sur une adresse et un port. Le serveur ouvre deux autres écouteurs, chacun uniquement si vous l’activez. | Écouteur | Activé par défaut | Adresse par défaut | Ce qu’il demande | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Requêtes API | Oui | `127.0.0.1:8400`, qui n’est accessible que depuis la même machine. Pour modifier l’adresse et le port, définissez `server.addr`. | Consultez [Identifiants acceptés par le serveur](https://platform.claude.com/docs/fr/managed-agents/self-hosted-data-and-access#credentials-that-the-server-accepts). | | La [console de votre serveur](https://platform.claude.com/docs/fr/managed-agents/self-hosted/console), une page web | Oui. Pour cesser de la servir, consultez [Désactiver la console](https://platform.claude.com/docs/fr/managed-agents/self-hosted/console#turn-off-the-console). | La même adresse et le même port que les requêtes API | Rien pour charger la page, pour toute personne qui peut l’atteindre. Pour effectuer une action dans la console, une personne se connecte via votre fournisseur d’identité. | | Le point de terminaison de métriques Prometheus | Non | `localhost:9464`, qui n’est accessible que depuis la même machine | Aucun identifiant | | L’écouteur du serveur pour la [passerelle de sortie](https://platform.claude.com/docs/fr/managed-agents/self-hosted/agent-identity#environment-variable-credentials) | Non | Port 8410 sur chaque interface | La clé de la passerelle | Plus de détails sur les deux derniers écouteurs : * **Le point de terminaison de métriques Prometheus :** Il ne demande aucun identifiant ; qui peut l’atteindre dépend donc de l’endroit où il écoute. Si vous définissez `OTEL_METRICS_EXPORTER` sur `prometheus` sans définir d’adresse, il écoute sur l’adresse par défaut. Si vous l’activez via le chart Helm du serveur, il écoute sur le port 9464 de chaque pod du serveur. Tout ce qui dispose d’une route vers l’adresse d’un pod peut alors l’atteindre, sauf si une NetworkPolicy bloque ce trafic. * **L’écouteur pour la passerelle de sortie :** La passerelle de sortie est un proxy facultatif entre vos sandboxes et Internet. Le serveur écoute la passerelle sur un port distinct. Cet écouteur utilise du HTTP simple, et ses réponses contiennent des valeurs d’identifiants stockées. La pile Compose et le chart Helm du serveur ne laissent que la passerelle l’atteindre. Si vous exécutez le serveur d’une autre manière, faites de même. La pile Docker Compose publie le port 8400 sur l’adresse de bouclage de l’hôte Docker, `127.0.0.1`. Exécutez Docker Engine 28.3.3 ou une version ultérieure. Avec certaines versions antérieures, les machines du réseau local de l’hôte peuvent atteindre un port publié sur l’adresse de bouclage. Pour publier le port sur une autre adresse, définissez `CMA_PUBLISH_ADDRESS` dans `.env`. ## Multilocation Chaque déploiement sert un seul « tenant » (locataire) à un seul niveau de confiance. Les environnements d’un même déploiement ne séparent pas les niveaux de confiance. La clé API du serveur atteint chaque environnement. Chaque appelant disposant d’un rôle peut exécuter des sessions dans chaque environnement, avec l’ensemble du réseau et des fichiers que les workers de cet environnement peuvent atteindre. | Pour séparer | Procédez ainsi | | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Les locataires | Attribuez à chaque locataire son propre déploiement, avec sa propre base de données, sa propre clé API de serveur et ses propres workers. | | Les charges de travail de niveaux de confiance différents | Attribuez à chaque niveau de confiance son propre déploiement, configuré comme pour un locataire. Il peut s’agir par exemple de code de confiance et de code non fiable, ou de workers qui atteignent des systèmes que seuls certains appelants peuvent utiliser. | | Les appelants d’un même déploiement | Activez l’[authentification unique](https://platform.claude.com/docs/fr/managed-agents/self-hosted/configure#single-sign-on), associez les groupes au rôle `developer` ou `user`, et réservez la clé API du serveur aux administrateurs. [Ce que chaque rôle peut faire](https://platform.claude.com/docs/fr/managed-agents/self-hosted/configure#what-each-role-can-do) montre ce que voient ces appelants. | ### Gestionnaires de secrets, authentification unique et passerelles de modèles Si vos déploiements utilisent l’un de ces services, séparez-les également à ce niveau : * **Gestionnaire de secrets :** Séparez les secrets des déploiements, comme l’indiquent les [limites du gestionnaire de secrets](https://platform.claude.com/docs/fr/managed-agents/self-hosted/agent-identity#limits). * **Authentification unique :** Attribuez à chaque déploiement des entrées `audiences` qu’aucun autre déploiement ne liste, afin qu’il refuse les jetons des autres déploiements. Dans le déploiement de chaque niveau de confiance, n’attribuez un rôle qu’aux appelants autorisés à ce niveau, et ne définissez aucun `default_role`. * **[Passerelle de modèles](https://platform.claude.com/docs/fr/managed-agents/self-hosted/inference-provider#model-gateway) :** Pour distinguer les déploiements, attribuez à chacun sa propre valeur pour un en-tête tel que `x-tenant-id` sous `inference.headers`. ### Ce que les rôles ne limitent pas Les rôles ne limitent que les requêtes qu’un appelant effectue avec son propre jeton. Le code qu’un agent exécute peut appeler le serveur avec n’importe quel identifiant que contient sa sandbox. Une [clé d’environnement](https://platform.claude.com/docs/fr/managed-agents/self-hosted#the-three-credentials) peut lire les événements et publier des résultats d’outils dans chaque session de son environnement. Exécutez donc chaque session dans une sandbox qui lui est propre, et gardez la clé d’environnement hors de cette sandbox. Les piles présentées dans [Premiers pas avec Claude Managed Agents auto-hébergé](https://platform.claude.com/docs/fr/managed-agents/self-hosted/quickstart) et [Déployer sur Kubernetes](https://platform.claude.com/docs/fr/managed-agents/self-hosted/kubernetes) procèdent ainsi.