Les agents de code lisent des fichiers, exécutent des tests et utilisent des outils. Une clé présente dans le dépôt, une variable trop large ou un journal verbeux peut donc se retrouver dans le contexte ou dans une sortie externe.
Cartographier les secrets accessibles
Listez les variables, fichiers de configuration, gestionnaires de secrets, identifiants cloud et jetons CI. Pour chaque tâche, demandez si l'agent en a réellement besoin. La réponse est souvent non.
Donner une identité minimale
Utilisez des comptes de service dédiés, des scopes réduits et des jetons courts. Séparez lecture, écriture et production. Ne réutilisez pas le jeton personnel d'un administrateur.
Bloquer avant le commit
Activez le secret scanning et la push protection. GitHub précise cependant que la détection possède des limites selon les formats et la taille des pushes. Ajoutez des motifs personnalisés et un contrôle local pour les secrets internes.
Un contournement doit être exceptionnel, justifié et approuvé par une autre personne. Un faux positif ne doit pas devenir une habitude de bypass.
Filtrer les traces et les prompts
Masquez les valeurs avant journalisation. N'enregistrez pas par défaut les arguments complets des outils, car les conventions OpenTelemetry avertissent qu'ils peuvent contenir des informations sensibles.
Les fichiers .env, clés privées, sauvegardes et exports doivent être exclus du contexte et du dépôt. Une règle écrite ne suffit pas : imposez la restriction au niveau de l'environnement.
Réagir à une fuite
- Révoquer immédiatement le secret.
- Émettre un nouvel identifiant avec un scope minimal.
- Rechercher la valeur dans l'historique, les logs et artefacts.
- Nettoyer sans considérer la réécriture Git comme une révocation.
- Documenter la cause et ajouter un contrôle préventif.
Complétez cette démarche avec la sécurité MCP et le choix entre IA locale et cloud.
Menace particulière : l'injection indirecte
Un fichier README, une issue ou une page consultée par l'agent peut contenir une instruction qui demande d'ouvrir .env ou d'envoyer une valeur vers un domaine externe. Le texte récupéré ne doit jamais modifier la politique d'accès. Les restrictions réseau et fichiers doivent être appliquées par l'environnement, pas seulement rappelées dans le prompt.
Séparer développement et production
Créez des secrets de test sans valeur en production et utilisez des comptes distincts. Un agent qui prépare une migration peut travailler sur un jeu de données synthétique. L'étape de production reçoit uniquement l'artefact validé, pas toute la session de développement.
Tester les protections
Ajoutez volontairement de faux secrets correspondant à vos motifs internes dans une branche de test. Vérifiez le blocage local, la CI, la push protection et l'alerte. Testez également le masquage dans les traces et la révocation.
Checklist avant délégation
- Répertoires sensibles exclus techniquement.
- Identité dédiée et scopes minimaux.
- Réseau limité aux domaines nécessaires.
- Secret scanning actif avant le push.
- Arguments d'outils filtrés dans les traces.
- Procédure de révocation testée.
- Bypass soumis à une revue indépendante.
quelle étape de votre workflow accepteriez-vous de déléguer à un agent, et laquelle garderiez-vous obligatoirement sous contrôle humain ?
Publié dans la discussion