Le problème : un workflow privilégié qui exécute du code non relu

Un workflow déclenché par pull_request_target s’exécute avec le jeton du dépôt principal, ses secrets et l’accès au cache de la branche par défaut. Si ce workflow récupère le code d’une pull request venue d’un fork, puis l’exécute (installation de dépendances, tests, build), le code d’un inconnu tourne avec tous ces privilèges. GitHub appelle ce schéma une « pwn request » et rappelle qu’il a été la cause de plusieurs incidents de chaîne d’approvisionnement.

Le 18 juin 2026, actions/checkout v7 est devenu disponible pour tous et refuse ce schéma par défaut : il ne récupère plus le code d’une pull request issue d’un fork dans pull_request_target, ni dans workflow_run lorsqu’il est déclenché par une pull request. GitHub a reporté au lundi 20 juillet 2026 l’application de cette règle aux versions plus anciennes ; les workflows qui utilisent une étiquette flottante comme actions/checkout@v4 en bénéficient automatiquement. Il reste possible de désactiver la protection avec l’option allow-unsafe-pr-checkout, dont le nom a été choisi pour sauter aux yeux en revue de code.

Qui a le droit de déclencher un workflow ?

Le même jour, GitHub a ouvert en préversion publique des protections d’exécution des workflows, gérées par les « rulesets » au niveau de l’entreprise, de l’organisation ou du dépôt. Deux types de règles : les règles d’acteurs (utilisateurs, rôles comme Read, Maintain ou Admin, applications GitHub, Copilot et Dependabot) et les règles d’événements (push, pull_request, pull_request_target, workflow_dispatch). Un mode « évaluation » permet de faire tourner les règles en observation avant de les appliquer, pour voir ce qu’elles auraient bloqué.

Avec des agents de code, ce point devient central : le compte d’un agent qui propose des modifications n’a aucune raison de pouvoir lancer un déploiement en production. Séparer « proposer » et « déployer » est la base du moindre privilège.

AGENTS.md : écrire les règles du dépôt pour les humains et pour les agents

Toujours le 18 juin, la revue de code Copilot a commencé à lire le fichier AGENTS.md placé à la racine du dépôt, pour adapter ses remarques aux conventions du projet. C’est une bonne occasion de rédiger ce fichier, utile à tous les agents qui le lisent comme aux nouveaux arrivants. Un AGENTS.md utile tient en une page :

  • les commandes pour installer, tester et construire le projet ;
  • les conventions (nommage, style, structure des dossiers) ;
  • les interdits explicites : aucun secret dans le code, aucun « force push », aucune migration destructive sans validation ;
  • la définition de « terminé » : tests verts, revue humaine, documentation à jour.

Ce sont les mêmes garde-fous que Prompt OS ajoute à chaque mission confiée à Codex, Claude Code ou un autre agent : écrits une fois, appliqués partout.

Exemple : séparer tester et publier

La correction la plus fréquente que nous appliquons est simple. Pour faire tourner les tests d’une contribution extérieure, l’événement pull_request suffit : il s’exécute sans les secrets du dépôt et avec un jeton en lecture seule. L’événement pull_request_target doit être réservé aux tâches qui n’exécutent pas le code proposé, comme ajouter une étiquette ou publier un commentaire.

on: pull_request
permissions:
  contents: read
jobs:
  tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: npm ci && npm test

Le déploiement, lui, se déclenche ailleurs : après la fusion sur la branche principale, par un workflow distinct, avec un environnement protégé qui exige une approbation humaine. Ainsi, ni un contributeur inconnu ni un agent qui propose des modifications ne peuvent atteindre les secrets de production. C’est la même logique que pour un collaborateur humain : on peut proposer sans pouvoir publier.

Liste de contrôle pour une petite équipe

  1. Rechercher pull_request_target et workflow_run dans .github/workflows et justifier chaque usage.
  2. Passer à actions/checkout v7 (ou vérifier l’étiquette flottante) et refuser en revue tout ajout de allow-unsafe-pr-checkout non argumenté.
  3. Déclarer des permissions minimales pour le jeton (permissions: contents: read par défaut, élargies job par job).
  4. Activer les règles de déclenchement en mode évaluation, observer deux semaines, puis les appliquer.
  5. Écrire un AGENTS.md court et le tenir à jour.
  6. Exiger une revue humaine avant la fusion de toute pull request produite par un agent.

Si votre site ou votre application a été construit en « vibe coding » et que personne n’a regardé la chaîne de déploiement, un audit de sécurité web commence précisément par là.

Conclusion

Les agents de code accélèrent le développement, mais ils multiplient aussi les pull requests, les déclencheurs et les jetons en circulation. Les changements de GitHub du 18 juin 2026 vont dans le bon sens : sûrs par défaut, contrôlables, lisibles. Il reste à les activer et à écrire ses propres règles — une demi-journée de travail qui évite les pires scénarios.