Avant d’étendre un workflow de développement assisté par IA, déterminez ce que vous devriez interrompre pour l’arrêter. Si la réponse inclut le compte d’un développeur, un service de build partagé ou un environnement entier, le coût de l’arrêt dépasse déjà le travail de l’outil lui-même.
Ce coût commence avec les accès que vous accordez. Un outil qui dispose de ses propres droits, limités, peut offrir un point d’arrêt plus étroit. Un outil qui hérite des accès de plusieurs personnes, ou qui s’appuie sur des identifiants partagés avec d’autres opérations, peut imposer une décision bien plus large lorsque quelque chose semble anormal.
Pour un directeur technique, la question pratique est de savoir si les accès et les dépendances du workflow correspondent à la limite que vous comptez utiliser sous pression. Fixez cette limite avant d’étendre le workflow, puis testez ce que l’arrêt empêche réellement et ce qu’il interrompt par ailleurs.
La décision d’arrêt commence avant la première exécution
Prenons un workflow de développement fictif. Un outil IA lit un ticket, récupère un dépôt, installe les dépendances, modifie le code, lance les tests et crée un déploiement de prévisualisation. Un développeur examine la modification proposée avant la fusion.
La revue avant fusion contrôle une étape importante. Les étapes précédentes méritent aussi l’attention. L’installation des dépendances ou la préparation d’un environnement peut exécuter du code. Le workflow peut donc utiliser ses droits avant qu’il existe une modification à examiner.
L’exécution à l’installation n’est pas un risque théorique. Le 26 août 2025, des attaquants ont publié sur npm des versions malveillantes de plusieurs paquets Nx. Selon le post-mortem de Nx, leur script post-installation analysait les systèmes des utilisateurs à la recherche de données sensibles, tentait d’utiliser les outils IA installés localement, comme Claude et Gemini, puis publiait les résultats dans un dépôt GitHub public via la CLI GitHub. Il utilisait ce à quoi la machine était déjà connectée. La revue d’une modification proposée ne l’aurait pas détecté : le script s’exécutait au moment de l’installation.
Imaginons que la configuration initiale utilise l’authentification existante d’un développeur pour accéder au dépôt et aux tickets. L’outil reçoit aussi un identifiant de déploiement partagé avec le service de build de l’équipe. C’est pratique : l’outil atteint tout ce dont il a besoin sans dispositif d’accès séparé.
Cela lie aussi le point d’arrêt de l’outil à ces autres activités. Révoquer l’identifiant de déploiement partagé pourrait interrompre des builds légitimes. Désactiver le compte du développeur pourrait affecter son travail ailleurs. Fermer l’interface de l’outil pourrait laisser tourner une tâche de déploiement lancée séparément.
Ce sont des conséquences de la configuration. Une procédure de réponse rédigée plus tard ne peut pas créer une limite indépendante que le modèle d’accès ne permet pas.
Avant la première exécution, établissez ce que le workflow peut lire, modifier et lancer, y compris par le biais d’une authentification héritée. Un registre des accès des agents IA est un endroit pratique pour le consigner, avec le chemin de révocation de chaque entrée. Suivez ces droits jusqu’aux systèmes externes. Le dépôt n’est qu’une partie du tableau si le même workflow peut aussi créer de l’infrastructure ou déclencher un autre service.
Un environnement séparé a toujours besoin d’une limite d’accès
Choisir le poste du développeur, un conteneur ou un environnement d’exécution distant change l’endroit où le code s’exécute. Ce choix ne décrit pas, à lui seul, les droits externes dont dispose ce code.
| Environnement d’exécution | Accès à examiner | Conséquence pour l’arrêt |
|---|---|---|
| Poste du développeur | Fichiers accessibles, outils connectés, identifiants et autres processus locaux | Arrêter ou isoler le poste peut interrompre les autres travaux du développeur. |
| Conteneur | Fichiers montés, accès réseau, identifiants injectés et authentification transférée | Supprimer le conteneur peut laisser des identifiants externes ou des tâches utilisables s’ils ne sont pas traités séparément. |
| Environnement distant | Droits sur le dépôt, secrets, services connectés et tâches lancées ailleurs | Mettre fin à l’environnement peut laisser actifs des sessions externes, des identifiants ou du travail délégué. |
Cette comparaison ne désigne aucun gagnant universel. Un conteneur avec des montages étendus et des droits de déploiement partagés peut conserver des dépendances que vous pensiez supprimer. Un environnement distant peut être configuré de façon étroite ou relié à de nombreux systèmes. Une authentification transférée peut conférer des droits sans copier la clé privée sous-jacente dans l’environnement.
Pour le workflow fictif, la bonne question de conception est précise : peut-il lire le ticket requis, proposer une modification du dépôt et déployer dans un projet de prévisualisation convenu sans acquérir les droits plus larges du développeur ?
Invariant Labs a montré ce que peuvent coûter ces droits plus larges. Dans sa démonstration sur le serveur MCP de GitHub, publiée en mai 2025, un agent relié au compte GitHub d’un utilisateur, avec accès à ses dépôts publics et privés, a lu un ticket malveillant dans un dépôt public. Il a ensuite chargé des données de dépôts privés dans son contexte et les a divulguées dans une pull request qu’il a créée dans le dépôt public. Invariant y voit un problème d’architecture au niveau du système d’agents, et non un défaut du code du serveur MCP de GitHub, et recommande de limiter l’accès de l’agent aux seuls dépôts dont il a besoin, par exemple un dépôt par session.
Demandez-vous ensuite si chaque connexion peut être retirée à la limite prévue. Si la plateforme ne permet pas la séparation nécessaire, modifiez le workflow ou acceptez explicitement un périmètre d’arrêt plus large avant de l’étendre.
Décider ce qu’une réaction a le droit d’interrompre
Supposons maintenant que le workflow tente une action en dehors du projet de prévisualisation convenu. L’équipe a besoin d’une politique de réponse qui nomme à la fois le déclencheur et l’interruption autorisée.
Cette politique peut autoriser à l’avance la suspension des nouvelles exécutions de l’outil, le blocage de nouveaux déploiements de prévisualisation et le retrait d’un identifiant dédié à ce workflow. Elle doit aussi traiter le travail déjà en file d’attente ou en cours. Suspendre les nouvelles exécutions ne dit pas ce qu’il est advenu d’une demande de déploiement déjà acceptée par un autre système.
La réaction autorisée dépend des conséquences de l’action comme de l’inaction. Un arrêt injustifié peut interrompre un travail légitime. Une réaction qui attend une personne peut laisser une action indésirable possible pendant l’attente. Ni l’action automatique ni la validation humaine ne donnent la bonne réponse pour chaque limite.
La conception des accès rend cette décision plus facile ou plus difficile. Avec une identité de prévisualisation dédiée, le retrait des droits de déploiement peut avoir un périmètre défini. Avec une identité partagée, la même réaction peut toucher des builds sans rapport. La commodité apparente du partage d’accès est devenue un coût de réponse.
Consignez qui ou quoi peut arrêter le workflow, quelles actions sont autorisées à l’avance et quand l’escalade s’applique. Si l’événement dépasse la limite prévue, un arrêt d’urgence plus large peut se justifier selon la politique d’escalade convenue. Préserver les opérations courantes est un critère parmi d’autres ; il ne doit pas devenir une raison de laisser tourner une activité nuisible.
Là où nous plaçons la limite : le système peut arrêter ce qui appartient à ce seul workflow, par exemple suspendre ses nouvelles exécutions, annuler ses propres tâches en file d’attente et révoquer son identifiant dédié. Désactiver tout ce dont dépend un autre travail, comme un compte partagé, le service de build ou l’identité d’un développeur, exige une personne, sauf si la politique d’escalade convenue couvre déjà l’événement.
Donner au workflow une limite que vous pouvez actionner
Reprenons la configuration fictive. Lorsque c’est possible, l’outil reçoit une identité limitée aux actions nécessaires sur le dépôt et un identifiant distinct pour son projet de prévisualisation. Ses tâches en file d’attente sont identifiables. Le circuit de build habituel de l’équipe utilise d’autres droits.
Cela crée une option d’arrêt plus précise. L’équipe peut tenter d’arrêter le travail de ce workflow et de retirer ses accès sans devoir désactiver immédiatement tout le compte du développeur ou le service de build partagé.
Cette séparation doit encore être vérifiée. Le circuit de build habituel dépend peut-être d’un fichier ou d’un service que l’outil peut modifier. Une tâche en file d’attente continue peut-être sous une autre identité. Plusieurs workflows partagent peut-être l’environnement que vous comptez arrêter. Séparer les identifiants traite une dépendance ; cela n’établit pas l’indépendance sur toute la chaîne.
Définissez la limite en termes opérationnels : les exécutions à suspendre, les processus ou tâches à traiter, les droits à retirer et les opérations légitimes qui doivent continuer. Gardez disponible un chemin d’administration de confiance, extérieur à l’outil et à l’environnement potentiellement compromis, pour arrêter le travail, retirer les identifiants et confirmer les résultats. Il doit utiliser des droits que le workflow ne peut pas modifier. Un bouton « arrêter » dans l’outil concerné ne constitue pas une preuve suffisante.
Tester un arrêt contrôlé sur un travail jetable
Avant d’étendre le workflow, menez un exercice contrôlé avec des tickets, du code et des ressources de prévisualisation fictifs, dans un environnement jetable et avec des identifiants de test uniquement. Pour ce workflow fictif, l’arrêt prévu retire les droits de lecture des tickets, de lecture et d’écriture sur le dépôt et de déploiement de prévisualisation. Désignez toute connexion volontairement conservée comme une limite plus étroite.
L’exercice pourrait se dérouler ainsi :
- Établissez des actions de référence sans risque : lire un ticket fictif, lire et pousser une branche témoin dans le dépôt de test, et lancer une tâche de prévisualisation de test. Notez les identifiants et les chemins de session utilisés.
- Vérifiez qu’un build de test sans rapport fonctionne avec l’identité de build distincte de l’équipe. Notez le résultat attendu.
- Par le chemin d’administration de confiance, suspendez les nouvelles exécutions et retirez les accès prévus, y compris les sessions existantes concernées. Examinez et traitez séparément les tâches en file d’attente ou en cours.
- Depuis un client de test contrôlé et indépendant, tentez chaque action de référence avec la même identité de test, le même identifiant et les chemins de session concernés. Attendez un refus du système de destination pour chaque droit retiré. Ne vous fiez pas à l’exécuteur suspendu ni à ses messages pour établir le refus.
- Utilisez le chemin d’administration pour confirmer l’état des tâches, puis relancez le build de test sans rapport et vérifiez son résultat.
Un nouveau client ne reproduit pas forcément toutes les sessions existantes. Consignez comme non résolu tout chemin de session que vous ne pouvez ni tester ni examiner. Si une action censée être refusée aboutit, la limite ne s’est pas comportée comme prévu. Si le build sans rapport échoue, examinez la dépendance partagée avant d’affirmer que le workflow peut être arrêté de façon indépendante. Un état de tâche inconnu reste lui aussi non résolu.
Un exercice réussi apporte des éléments pour ces ressources, ces chemins d’accès et ces conditions. Il ne prouve pas que toute action possible est maîtrisée, qu’aucune information n’a été copiée auparavant ni que l’activité resterait ininterrompue lors d’un événement réel.
Répétez les vérifications concernées lorsque les droits, les intégrations ou les dépendances changent. Le résultat utile est une limite d’arrêt dont vous pouvez expliquer le comportement à partir d’éléments vérifiés.
Deux conseils que nous contesterions
« Il suffit de relire le code généré. » La revue contrôle ce qui est fusionné. Elle ne contrôle pas ce qui s’est exécuté en chemin. L’installation des dépendances, la préparation de l’environnement et les tests exécutent du code avant qu’il existe un diff à lire, avec les droits dont dispose le workflow à ce moment-là. Le script Nx a agi au moment de l’installation.
« Une personne doit confirmer chaque action. » Dans la démonstration d’Invariant, Claude Desktop demandait par défaut à l’utilisateur de confirmer chaque appel d’outil. Invariant note que de nombreux utilisateurs passent à une politique « Toujours autoriser » et cessent de surveiller les actions une à une. Des confirmations répétées des dizaines de fois cessent d’être une vérification, et elles n’agissent qu’à l’intérieur de l’outil qui les demande : un bouton de confirmation n’arrête pas une demande de déploiement déjà acceptée par un autre système. Nous abordons la conception des validations dans Agents IA : quand les garde-fous deviennent le problème. Placez une personne là où la conséquence est difficile à annuler, et rendez le reste arrêtable.
Séparer l’arrêt, la réparation et le redémarrage
Révoquer des accès, arrêter le travail, annuler des effets et décider si un environnement reste fiable répondent à des questions différentes.
La révocation concerne l’usage futur des droits ; son effet sur les sessions existantes et le travail déjà accepté doit être vérifié. L’arrêt concerne les processus et les tâches qui peuvent continuer d’agir. Aucune de ces actions ne restaure un fichier modifié, n’annule un changement externe ni ne rappelle une information déjà divulguée.
La réparation exige donc sa propre évaluation. Établissez ce qui a changé et ce qui peut être restauré. Évaluez si l’environnement reste fiable, y compris sa configuration et tout ce qui pourrait s’exécuter au redémarrage. Si nécessaire, reconstruisez à partir d’une configuration connue plutôt que de considérer un processus silencieux comme la preuve d’un environnement sain.
Le redémarrage est une décision supplémentaire. Confirmez les accès prévus, levez les incertitudes concernées et décidez quels éléments suffisent pour reprendre dans le périmètre convenu. Pouvoir redémarrer l’outil ne prouve pas qu’il soit opportun de le faire.
Quand un client nous dit « si l’IA commence à faire n’importe quoi, on l’éteindra », notre réponse est : « L’éteindre arrête l’action suivante, pas celle qui est déjà en cours. Le temps que vous vous en aperceviez, une tâche peut tourner ailleurs sous une clé partagée, et le seul interrupteur dont vous disposez peut aussi couper vos builds ou le compte d’un développeur. Alors, avant d’étendre un workflow, nous lui donnons quelque chose de petit à éteindre, puis nous testons que l’éteindre l’arrête vraiment. »
Avant d’étendre votre workflow, notez la plus petite limite que vous comptez arrêter, les droits qui la rendent possible et les opérations métier qui en dépendent. Puis exercez cette limite. Si le résultat exige une interruption plus large que prévu, modifiez les accès ou les dépendances tant que le workflow reste limité.
Apportez-nous le workflow que vous voulez étendre
IZZY peut examiner la configuration, les accès, les secrets, les contrôles, le code et les éléments justificatifs d’un workflow IA convenu. Apportez le workflow que vous voulez étendre et la limite d’arrêt que vous devez évaluer.
Cet examen relève de notre service Sécurité IA & durcissement du code.