Un agent qui peut lancer des commandes peut lancer la mauvaise. Réduisez le rayon d’impact par couches : bac à sable, liste d’autorisations, secrets restreints et humain devant l’irréversible.
Leçon 19 / 24 · ⏱ 8 min
Un agent qui peut lancer des commandes peut supprimer un dossier, pousser une branch ou lire votre fichier d’identifiants. D’habitude, il ne le fera pas. Les garde-fous, c’est pour le jour où il le fait.
Je ne compte pas sur le bon comportement de l’agent. Je conçois l’environnement pour que, quand il se trompe, les dégâts restent petits et réversibles.
Pensez en rayon d’impact
Aucun garde-fou ne suffit seul. Chaque couche attrape ce que la précédente a manqué, et la question est la même pour chacune : si l’agent se trompe ici, quel est le pire scénario?
La défense en profondeur. L’agent est au centre. Chaque anneau qu’il doit franchir pour causer des dégâts est une occasion de l’arrêter.
Permissions : permettre l’ennuyant, demander pour le reste
La plupart des agents de code vous laissent choisir quelles actions roulent automatiquement et lesquelles demandent votre approbation. Le piège, c’est de tout approuver parce que les demandes deviennent agaçantes.
✕ La fatigue d’approbation
–Chaque commande demande, alors vous cliquez oui sans lire
–Tôt ou tard, vous désactivez les approbations au complet
–La seule commande dangereuse passe comme les autres
✓ Une liste d’autorisations réfléchie
+Lire des fichiers, lancer les tests, la commande de vérification : automatique
+Installer des paquets, toucher à la config, utiliser le réseau : demander
+Pousser, déployer, supprimer hors du dépôt : bloqué
+Les rares demandes qui restent valent la peine d’être lues
Secrets : partez du principe que l’agent peut les lire
Si un secret est dans l’environnement de l’agent ou n’importe où qu’il peut lire, considérez qu’il peut se retrouver dans un journal, un commit ou un prompt. Gardez les identifiants de production complètement hors des environnements d’agents.