bac à sable (sandbox)

En profondeur

Le raisonnement à tenir est celui du moindre privilège, connu de longue date en sécurité et particulièrement adapté ici. Un agent reçoit exactement les accès nécessaires à sa tâche, et rien de plus : ce dépôt en lecture, cette boîte aux lettres en écriture, ce domaine en réseau. Tout le reste est absent, non pas interdit. La différence est décisive parce que le comportement d’un modèle n’est pas garanti : une instruction dissimulée dans un document peut lui faire tenter une action, et seule l’absence de l’accès l’empêche d’aboutir.

Les frontières à poser sont au nombre de quatre, et les oublier revient à n’avoir rien posé. Le système de fichiers, en limitant à un répertoire de travail jetable. Le réseau, en n’autorisant que les destinations nécessaires, car un accès sortant ouvert est un canal d’exfiltration. Les identifiants, en ne fournissant que des jetons de portée réduite et de durée courte. Et les ressources, en bornant temps, mémoire et nombre d’appels, faute de quoi une boucle qui s’emballe se paie en facture.

Le bac à sable est aussi ce qui rend un agent testable. Puisque son environnement est reconstruit à l’identique, on peut rejouer un scénario, comparer deux versions du système et vérifier une correction. Une exécution qui agit directement sur le réel n’est ni reproductible ni annulable, donc ni évaluable. Cette propriété explique que les agents les plus avancés opèrent d’abord dans un environnement isolé et ne portent leurs changements au réel qu’à la fin, après validation.