Menu

Quand un agent se fait passer pour un collaborateur

Catégories

Tags

🔍 Licence d'Utilisation 🔍

Sauf mention contraire, le contenu de ce blog est sous licence CC BY-NC-ND 4.0.

© 2025 à 2042 Sébastien Gioria. Tous droits réservés.

⏱️
Temps de lecture estimé
2 min de lecture

Pillar Security a démontré qu’une simple issue GitHub publique suffisait à faire poster, par un agent de triage, la commande qui déclenche un agent bien plus privilégié. Google a répondu en supprimant purement et simplement trois workflows du dépôt adk-python.

Le contrôle d’accès n’était pas absent. Il faisait exactement ce pour quoi il avait été écrit : vérifier qui avait posté la commande. Il ne pouvait pas vérifier si cette identité avait été manipulée pour la poster.

Posons le décor

Le dépôt adk-python, l’Agent Development Kit de Google pour Python, automatisait son triage avec des agents. Trois workflows, dont deux qui nous intéressent :

  • issue-analyze.yml : déclenché automatiquement à l’ouverture de toute issue, y compris par un parfait inconnu. Il s’authentifie avec ADK_GCP_SA_KEY, fait analyser l’issue par un agent, et poste le résultat en commentaire via le compte adk-bot.
  • issue-fix.yml : nettement plus privilégié. Il écoute les commentaires contenant la commande /adk-issue-fix, et engage un agent capable de générer et de pousser du code. Toutes les capacités de l’agent y sont activées.

Le troisième, pr-analyze.yml, suit la même logique côté pull requests.

Entre les deux, un contrôle d’accès. Il existe, il est explicite, et il n’est pas naïf : issue-fix.yml ne se déclenche que si l’auteur du commentaire est Collaborator, Member ou Maintainer. C’est exactement ce qu’on recommande, c’est ce que j’aurais moi-même validé en revue d’architecture il y a quelques mois.

Sauf qu’adk-bot est enregistré comme collaborateur du dépôt. Il faut bien qu’il le soit : sans ça, il ne pourrait pas commenter.

Note du PandaRedacteur : le compte de service qu’on ajoute aux collaborateurs « juste pour qu’il puisse commenter », et qui se retrouve six mois plus tard à détenir les clés du royaume parce que la gâchette du workflow privilégié regarde la liste des collaborateurs. On n’a rien inventé depuis les comptes de service AD des années 2000.

📬 Analyse complète réservée aux abonnés payants
L'analyse détaillée (STRIDE complet, règles de conception, pseudo-code de balayage des workflows) part d'abord aux abonnés payants de ma newsletter Substack, avant d'être publiée intégralement ici. Pour la lire en avant-première, c'est sur sgioria.substack.com.

📚 Références

À retenir 📌

  • ✓ Une issue GitHub publique suffisait à faire poster par l'agent de triage de Google la commande /adk-issue-fix, déclenchant un agent privilégié. Ni compte, ni code, ni credentials nécessaires.
  • ✓ Le contrôle d'accès vérifiait l'identité de l'auteur, pas la provenance de l'intention : adk-bot étant collaborateur, sa commande passait la gate.
  • ✓ Aucun des deux workflows n'était individuellement mal conçu : la vulnérabilité naît de leur composition, quand la sortie de l'un devient le déclencheur de l'autre.
  • ✓ L'allowlist de commandes shell a été contournée par un hook git : un agent qui peut écrire un fichier peut faire exécuter du code sans lancer de commande interdite.
  • ✓ Google a supprimé les trois workflows plutôt que de les durcir, et c'est la bonne réponse : il n'existe pas de version sûre de cette topologie.
LinkedIn Reddit Substack