Les bacs à sable pour agents expliqués : pourquoi TrueForge traite le bac à sable comme un outil

Un bac à sable peut isoler l'exécution de code, de fichiers et de shell sans devenir l'environnement d'exécution complet de l'agent. Ce choix modifie les coûts, l'exposition des identifiants, le cycle de vie et la sémantique de récupération.

Un bac à sable répond à une question plus restreinte que « l'agent est-il sûr ? »

Un agent peut avoir besoin d'exécuter du code, de manipuler des fichiers, d'inspecter un dépôt ou de lancer des commandes shell. Ces opérations ne doivent pas partager une limite de processus non restreinte avec le serveur d'orchestration ou l'infrastructure de production de l'organisation. Un bac à sable crée un environnement d'exécution contraint pour ces tâches.

Mais « agent en bac à sable » est une expression imprécise. Elle peut signifier que toute la boucle de l'agent s'exécute dans une machine isolée, y compris les clients de modèles, les identifiants d'outils et l'état. Ou bien elle peut signifier que la boucle de l'agent reste dans un environnement d'exécution géré et n'invoque un environnement isolé que pour les tâches gourmandes en exécution. TrueForge choisit la seconde conception : le bac à sable comme outil.

Cette distinction modifie ce qui est isolé, le moment où le calcul existe, l'emplacement des secrets et ce qui survit à une défaillance. Elle empêche également le bac à sable de devenir une étiquette de sécurité magique. La limite ne protège que les opérations et le trafic réellement placés derrière elle.

L'architecture maintient le modèle porteur de secrets et les clients MCP du côté du harnais tout en offrant aux travaux de code et de shell une limite d'exécution distincte. Le connecteur est un chemin de capacité, et non un transfert d'identifiants dans le bac à sable.

Deux architectures, des compromis différents

Dans une architecture « agent-inside-sandbox », chaque exécution ou environnement d'agent peut contenir la boucle d'orchestration, le client de modèle, les outils, les identifiants et les fichiers de travail. L'isolation est conceptuellement simple car la plupart des activités se déroulent à l'intérieur d'une seule limite. Les coûts sont un provisionnement plus lourd, une injection de secrets plus complexe et des reconstructions d'images lorsque les dépendances d'exécution changent.

Dans l'architecture « sandbox-as-tool » documentée de TrueForge, la boucle de l'agent s'exécute sur le serveur TrueForge. Le bac à sable n'est provisionné que lorsque l'agent a besoin de code, de fichiers, de shell, d'une compétence ou du mode Code. Les échanges conversationnels simples et les appels MCP ne nécessitent pas de calcul en bac à sable. Les identifiants du modèle et du MCP restent dans le harnais, et les appels MCP du mode Code sont redirigés vers le harnais plutôt que de fournir ces jetons au bac à sable.

Cela réduit la surface exposée aux secrets et permet à l'état de la conversation de survivre à un plantage du bac à sable. Cela signifie également que le bac à sable n'est pas le périmètre réseau pour chaque appel de modèle et d'outil. Le trafic vers le fournisseur de modèle et les opérations MCP proviennent du chemin du harnais, et ils nécessitent leurs propres contrôles de passerelle, d'identité, d'identifiants et de réseau.

Le cycle de vie documenté est limité à la session

TrueForge documente le bac à sable comme étant désactivé par défaut pour chaque agent. Lorsqu'il est activé et nécessaire, il est provisionné à la demande. Le bac à sable est réutilisé au fil des échanges dans la même session, de sorte que les fichiers persistent pendant que la conversation se poursuit. Après une période d'inactivité, il est arrêté, puis archivé et finalement supprimé conformément aux paramètres du fournisseur.

Ce cycle de vie est plus utile qu'un « conteneur jetable par invite », mais il soulève des questions de gestion d'état. Un fichier issu de l'échange 1 peut influencer l'échange 5. Une archive malveillante extraite tôt peut rester présente après que la tâche immédiate a été oubliée. Une dépendance installée lors d'un échange peut modifier une exécution ultérieure. La continuité de la session est une fonctionnalité ; l'accumulation d'état non géré est un risque.

Les applications doivent étiqueter les artefacts avec leur événement source, leur empreinte de contenu, leur classification de données et leur durée de vie prévue. Avant qu'un échange ultérieur n'exécute un fichier, vérifiez qu'il appartient toujours à la tâche active et que l'utilisateur actuel est autorisé à y accéder. Lorsque la reproductibilité est importante, enregistrez l'instantané du bac à sable ou l'identité de l'image, l'état de verrouillage des dépendances et les commandes qui ont produit l'artefact.

La réutilisation au fil des sessions est présentée à la fois comme une fonctionnalité et un risque. Si les fichiers permettent de conserver un travail utile après une interruption, chaque artefact restauré doit faire l'objet d'une traçabilité, d'une classification et d'une règle de cycle de vie, plutôt que de reposer sur la seule confiance accordée à la session.

Les identifiants situés hors du bac à sable réduisent l'autorité, sans toutefois l'éliminer.

Conserver les identifiants du modèle et du MCP dans le harnais empêche le code arbitraire du bac à sable de lire directement ces secrets. Il s'agit d'une frontière solide. Cependant, un script en bac à sable peut toujours demander au harnais d'effectuer un appel MCP via une passerelle contrôlée. La question de sécurité pertinente devient alors : quels appels ce code peut-il demander, avec quelle identité, en utilisant quels arguments et sous quelle politique ?

La passerelle doit exposer une capacité restreinte plutôt qu'un identifiant générique. Les définitions d'outils, l'identité du sujet, la destination, la classification des données, les budgets cumulés et les exigences d'approbation doivent être évalués en dehors du bac à sable. Les résultats renvoyés au code doivent être minimisés, car ils peuvent devenir des fichiers, des journaux ou des entrées de commande au sein de l'environnement.

De même, l'absence d'identifiants de modèle ne prouve pas que le bac à sable est dépourvu de sortie. La configuration du fournisseur détermine l'accessibilité réseau. Un déploiement robuste définit séparément les destinations sortantes, le comportement DNS, la politique d'installation des paquets, l'accès au service de métadonnées, les montages de système de fichiers, les limites de ressources et les contrôles de terminaison. TrueForge orchestre le fournisseur de bac à sable ; l'organisation reste responsable de la validation du fournisseur et de sa configuration au regard de son modèle de menace.

Cartographiez explicitement les frontières de confiance

Mise en évidence