Bac à sable local dans Kiro : gardez les commandes de l’agent dans des limites précises

Le bac à sable local de Kiro aide à protéger vos fichiers et vos identifiants locaux en limitant ce que les commandes et les scripts exécutés par l’agent peuvent consulter. Le système d’exploitation applique ces limites, ce qui réduit l’impact d’une commande erronée ou d’un script non fiable. Il est maintenant en disponibilité générale dans Kiro IDE et Kiro CLI.

De nombreux clients exécutent l’agent de Kiro IDE et de la CLI directement sur leur machine locale. L’agent voit ainsi le même système de fichiers, la même chaîne d’outils installée et les mêmes services localhost que vous, ce qui lui permet de compiler et de tester votre projet au lieu de raisonner à distance. Le revers de la médaille, c’est que chaque commande qu’il exécute porte vos privilèges et agit en votre nom. Accès complet au système de fichiers, accès complet au réseau, et rien au niveau du système d’exploitation qui distingue une commande choisie par l’agent de celle que vous avez saisie vous-même. Jusqu’ici, le seul contrôle était votre attention. Vous surveillez la session, vous lisez chaque commande avant de l’approuver et vous arrêtez tout ce qui semble suspect.

À mesure que les agents gagnent en capacités et que les développeurs en exécutent plusieurs en parallèle, votre attention peut devenir le goulot d’étranglement du système. Des tâches plus longues signifient plus de commandes, plus de commandes entraînent une fatigue d’approbation, et lancer une deuxième session ou vous absenter pendant une refactorisation signifie que les commandes sont bloquées ou que vous ne les lisez plus. Par ailleurs, les modes de défaillance n’exigent aucune intention malveillante. Un seul appel d’outil erroné ou une seule intention mal comprise peut devenir un véritable incident, et l’éventail des actions possibles était vaste. Par exemple, le modèle de confiance de Kiro refuse déjà à l’outil read_file de l’agent l’accès à ~/.aws et à ~/.ssh, mais un agent persistant pouvait tout de même lire ce même fichier au moyen d’un script exécuté dans le shell. La demande était bloquée, mais l’agent trouvait quand même un moyen d’arriver à ses fins. Le bac à sable infonuagique de Kiro, offert dans l’IDE, la CLI et Web, a répondu à ce problème en exécutant l’agent dans un environnement isolé. Cependant, beaucoup de travail doit rester local, que ce soit à cause de règles de résidence des données qui gardent le code hors du nuage, de services localhost et de ressources derrière un VPN, ou d’une compilation iOS qui exige Xcode et la chaîne d’outils d’Apple.

Avec le bac à sable local, l’agent continue de s’exécuter nativement et les commandes qu’il exécute en votre nom passent par un bac à sable appliqué par le noyau. Il s’appuie sur seatbelt sous macOS, sur bubblewrap sous Linux et sur AppContainer sous Windows. Ces restrictions sont appliquées par le système d’exploitation, en plus des vérifications d’autorisation des appels d’outils de Kiro. Vous accordez au bac à sable les permissions que vous souhaitez. Par exemple, les écritures sont limitées à votre répertoire de projet et à l’espace temporaire. Les lectures des chemins d’identifiants courants sont refusées dans le noyau, de sorte qu’un agent qui demande ~/.ssh/id_rsa essuie simplement un refus, sans aucun jugement à porter, et le même refus s’applique que la demande passe par read_file, par une commande shell d’une ligne ou par un script écrit pour faire la lecture à sa place. L’accès au réseau est forcé de passer par un mandataire local qui filtre par domaine, selon le même modèle que celui du bac à sable infonuagique, de sorte que l’agent atteint les services approuvés, comme les registres de paquets, tout en étant bloqué vers les autres destinations.

Nous avons délibérément laissé l’agent lui-même à l’extérieur du bac à sable. Seules les commandes qu’il exécute sont restreintes, ce qui vous permet d’activer ou de désactiver le bac à sable en cours de session et de modifier la politique sans redémarrer, car déplacer la frontière ne change que la façon dont la prochaine commande est encapsulée. Trois conséquences découlent de cette décision. L’identité de votre machine, soit les identifiants que l’agent utilise pour appeler le modèle et joindre le service principal de Kiro, n’entre jamais dans le bac à sable : un processus en bac à sable qui devient hors de contrôle ne peut donc pas s’en servir pour communiquer avec l’extérieur en votre nom. Vos serveurs MCP locaux continuent de fonctionner sans modification en tant que processus natifs de l’hôte, et vous pouvez aussi les faire passer par le bac à sable si vous voulez restreindre leurs actions. Enfin, il n’y a pas de bac à sable au sens traditionnel, seulement un processus enfant restreint, ce qui signifie qu’il n’y a rien dans lequel s’injecter, ni conteneur, ni image, ni machine virtuelle à démarrer avant l’exécution de la première commande.

Lorsque la protection du bac à sable est active, le travail local s’exécute dans des limites appliquées par le système d’exploitation. Une refactorisation, une boucle de compilation et de test ou une mise à niveau de dépendances s’exécute toujours sur votre machine, avec des restrictions sur les fichiers et les destinations réseau auxquels ses commandes peuvent accéder. L’activation du bac à sable limite ce qu’une commande peut faire après avoir été approuvée.

Le bac à sable est désactivé par défaut pour l’instant. Activez-le pour un espace de travail avec un fichier sandbox.json. Placez-le dans ~/.kiro/settings/sandbox.json pour une valeur par défaut globale, ou dans <project-root>/.kiro/settings/sandbox.json pour un remplacement propre au projet :

Vous pouvez aussi l’activer sans modifier le fichier. Dans Kiro CLI, exécutez /sandbox on dans une session locale (kiro-cli chat --v3), ou ouvrez /sandbox pour choisir la portée globale ou celle du projet, ainsi qu’un mode réseau. Dans Kiro IDE, exécutez Kiro: Open User Sandbox Config (JSON) à partir de la palette de commandes. La barre d’état affiche alors Command sandbox: Active. Sous Windows, exécutez d’abord la configuration unique par un administrateur : l’IDE vous la propose, et dans la CLI, vous exécutez /sandbox setup.

Cela suffit pour obtenir la politique par défaut. Votre répertoire de projet est accessible en écriture, les chemins d’identifiants courants sont refusés et l’accès au réseau passe par le mandataire local. Si vous voulez définir précisément ce que l’agent peut toucher, ajoutez des règles à permissions.yaml, le même fichier de politique qui régit déjà l’autorisation des outils aujourd’hui. Le bac à sable local n’introduit pas un second système de permissions à côté du modèle Workspace Trust existant. Ce sont les mêmes règles de capacité fs_read, fs_write et réseau, désormais aussi appliquées par le noyau du système d’exploitation, et non plus seulement à la frontière des outils. Voici un exemple de fichier ~/.kiro/settings/permissions.yaml :

La règle qui refuse l’appel de l’outil read_file de l’agent sur ~/.ssh/id_rsa refuse aussi la lecture du bac à sable au niveau du noyau, que l’agent y arrive par read_file, par une commande shell d’une ligne ou par un script qu’il écrit pour faire la lecture à sa place. Une seule politique de confiance, appliquée deux fois : la première lorsque l’agent demande poliment par un appel d’outil, la seconde lorsque le système d’exploitation vérifie l’appel système réel en dessous. La vérification de l’appel d’outil est nécessaire, mais insuffisante à elle seule, puisqu’elle n’attrape que les demandes qui passent par des outils que le moteur de politiques reconnaît. La vérification du noyau attrape tout le reste, y compris le contournement par script Python décrit plus haut. Comme elle lit directement votre politique existante, chaque portée que le moteur de politiques prend déjà en charge (administration, utilisateur, espace de travail, agent, session) s’applique automatiquement.

Est-il activé par défaut ?

Non. Activez-le globalement dans ~/.kiro/settings/sandbox.json, pour un seul projet dans <project>/.kiro/settings/sandbox.json, avec /sandbox on dans la CLI, ou à partir de la configuration du bac à sable dans l’IDE.

Quels systèmes d’exploitation sont pris en charge ?

macOS utilise Seatbelt. Linux utilise bubblewrap, que vous installez avec socat à partir des paquets de votre distribution. Windows utilise AppContainer après une configuration unique par un administrateur.

Cela empêche-t-il Kiro de demander une approbation ?

Non. Le bac à sable limite ce qu’une commande approuvée peut faire.

Le bac à sable local est offert dans Kiro IDE et dans la CLI. Consultez la documentation sur le bac à sable de commandes local pour connaître les détails de configuration et les modes réseau, ainsi que la documentation sur les permissions pour les règles sandbox_network.

Mettez à jour Kiro IDE vers la version 1.3 ou ultérieure, ou Kiro CLI vers la version 2.31 ou ultérieure (sessions V3 locales), pour l’essayer.