Garde-fous : ce qu'un agent de sécurité ne doit jamais faire seul

Les lignes à ne jamais laisser franchir

Reprenons les interdictions posées dans le brief (module 2) et détaillons pourquoi elles comptent vraiment :

• Accès aux secrets et credentials — un agent qui manipule des clés API, des tokens ou des mots de passe de production crée un point de défaillance supplémentaire. Le risque n'est pas hypothétique : une instruction ambiguë ou un raisonnement erroné suffit à provoquer une fuite.
• Commandes destructives — push --force, suppression de branche, reset --hard : aucune de ces commandes ne doit être exécutée sans confirmation humaine explicite, même dans le cadre d'une mission de sécurité légitime.
• Déploiement sans validation — un correctif, même correct, ne doit jamais partir en production directement depuis l'agent. La chaîne de revue habituelle (PR, CI, approbation) s'applique intégralement.
• Publication d'informations sensibles — un rapport de vulnérabilité détaillé, publié trop tôt ou au mauvais endroit, peut littéralement servir de mode d'emploi à un attaquant avant que le correctif soit déployé partout.

Le même réflexe qu'avec un junior

Ces garde-fous ne traduisent pas une méfiance envers l'agent en particulier — c'est le même cadre qu'on poserait pour n'importe quel nouveau contributeur, humain ou non, tant que la confiance ne s'est pas construite sur des résultats répétés. Un agent de sécurité qui a fait ses preuves sur des dizaines de missions cadrées reste soumis aux mêmes limites : la responsabilité finale ne se délègue pas.

Ce qui reste à faire

Poser des interdictions ne suffit pas si personne ne sait concrètement qui valide quoi, ni comment — c'est là que la revue humaine doit être structurée, pas improvisée.