Managed AgentsSandbox auto-hébergées

Modèle de sécurité

Copy page



Modèle de responsabilité partagée pour les environnements sandbox auto-hébergés.

Anthropic sécurise le plan de contrôle dans tous les environnements : intégrité des sessions et des files de travail, isolation multi-locataire et minimisation du contexte de l'agent. Lorsque vous auto-hébergez, les responsabilités suivantes vous incombent.

Ce qui relève de votre responsabilité

• Qualité de l'image sandbox et durcissement de l'environnement d'exécution. Anthropic n'inspecte ni ne vérifie votre image sandbox. Suivez les bonnes pratiques telles que la suppression des capacités Linux inutiles, l'exécution en tant qu'utilisateur non root et l'utilisation d'un système de fichiers racine en lecture seule.
• Contrôles de sortie réseau. L'accès réseau de votre sandbox est déterminé par votre VPC et vos règles de pare-feu. Sans restrictions de sortie (« egress »), une exécution d'outil compromise peut atteindre des hôtes externes arbitraires. Limitez le trafic sortant aux seuls points de terminaison dont vos outils ont besoin.
• Stockage et rotation de la clé de service. La clé de service de l'environnement (ANTHROPIC_ENVIRONMENT_KEY) autorise l'interrogation de la file de travail de votre environnement et la soumission des résultats aux sessions. Stockez-la dans un gestionnaire de secrets, et non dans des fichiers d'environnement ou des images sandbox. Effectuez sa rotation immédiatement si vous soupçonnez une exposition.
• Isolation des charges de travail non fiables. La clé de service de l'environnement est limitée à la file de travail d'un seul environnement. Si vous exécutez du code non fiable dans votre sandbox, envisagez de provisionner un espace de travail et un environnement distincts pour chaque frontière de confiance. Cela limite chaque clé aux sessions d'un seul utilisateur plutôt qu'à un pool partagé.
• Identifiants par session. Chaque élément de travail que votre worker réclame peut comporter un secret par session, que le worker du SDK utilise à la place de la clé de service de l'environnement. L'accès aux magasins de mémoire nécessite le secret : les points de terminaison des magasins de mémoire rejettent la clé d'environnement (voir Utiliser les magasins de mémoire). Ne transmettez le secret qu'à la sandbox qui sert cette session, gardez-le hors des images et des volumes partagés, et ne le journalisez jamais.
• Rayon d'impact de l'exécution des outils. Les outils s'exécutent dans votre sandbox avec les permissions dont dispose votre processus. Appliquez le principe du moindre privilège à l'utilisateur du processus et ne montez que les répertoires dont vos outils ont besoin.
• Conservation des journaux et contenu des sessions. Le contenu des conversations et les sorties des outils transitent par votre worker et restent dans votre environnement. Vous êtes responsable de la conservation, de la rédaction ou de la suppression de ces données conformément à vos propres politiques. Anthropic n'a aucune visibilité sur ce que votre worker fait du contenu des sessions une fois celui-ci livré.
• Contenu des magasins de mémoire. Les magasins de mémoire restent hébergés par Anthropic, y compris leur historique de versions. Lorsqu'une session en attache un, le worker conserve une copie de travail sous /mnt/memory/ dans votre sandbox pendant la durée de la session et synchronise les modifications en retour. Le worker supprime cette copie à la fin de la session, mais un worker qui se termine sans exécuter sa procédure de démontage la laisse en place. Le nettoyage des copies résiduelles, les permissions sur ce chemin et l'isolation entre les sessions qui partagent un système de fichiers relèvent de votre responsabilité.
• Magasins de mémoire en lecture seule. Un magasin attaché avec un accès read_only est protégé contre le téléversement, et non contre la modification locale. Les outils write et edit du worker refusent d'écrire dans son répertoire, rien de ce qui s'y trouve n'est synchronisé en retour, et les points de terminaison des magasins de mémoire rejettent les écritures effectuées avec le secret de la session. D'autres processus dans la sandbox peuvent toujours modifier la copie locale : les commandes que l'agent exécute via l'outil bash, ainsi que les outils personnalisés ou les serveurs MCP que vous servez depuis la sandbox, qui s'exécutent avec les permissions du worker. Les appels d'outils ultérieurs dans cette session lisent la copie modifiée jusqu'à ce que cette mémoire change à nouveau dans le magasin. Si l'agent ne doit pas pouvoir altérer même sa vue locale d'un tel magasin, désactivez l'outil bash pour cet agent et ne lui donnez aucun outil personnalisé qui écrit dans le système de fichiers de la sandbox.

Ce qu'Anthropic ne peut pas faire pour vous

• Savoir que votre clé a fuité. Anthropic peut détecter des schémas d'utilisation anormaux, mais ne peut pas savoir que votre clé a été compromise. Si vous soupçonnez que ANTHROPIC_ENVIRONMENT_KEY a fuité, révoquez-la et générez immédiatement une clé de remplacement. La révocation est validée à chaque requête, elle prend donc effet dès le prochain appel du worker.
• Vérifier la construction de votre worker. Anthropic n'inspecte ni votre image sandbox ni votre environnement d'exécution. Une compromission de la chaîne d'approvisionnement dans votre image n'est pas détectable depuis le plan de contrôle.
• Isoler les outils à l'intérieur de votre sandbox. La frontière de sécurité d'Anthropic s'arrête à la sandbox. La manière dont vous isolez les exécutions d'outils individuelles les unes des autres à l'intérieur de cette frontière relève entièrement de votre responsabilité.
• Appliquer la conservation des données dans votre environnement. Une fois que le contenu des sessions atteint votre worker, il échappe aux contrôles du cycle de vie des données d'Anthropic.