Résumé

  • Une étude de cas du gouvernement britannique décrit un chemin d’exécution de code déclenché par un commentaire dans le workflow d’un service numérique public; elle ne relève aucun signe d’exploitation.
  • Le pilote a recensé 407 constats dans neuf organisations publiques. Des spécialistes ont revérifié l’exposition et traité les faux positifs; toutes les faiblesses critiques ont été corrigées.

Le nombre de constats mesure la détection; il ne dit pas, à lui seul, si le risque a diminué. Le bilan décrit un mois de travail dans neuf organisations publiques et 407 constats au total. Certains étaient déjà connus et compensés par d’autres mesures; d’autres n’avaient pas été repérés auparavant. Les faiblesses critiques concernaient notamment le contournement de l’authentification, l’exposition de données et l’exécution de code à distance. Toutes les faiblesses critiques ont été corrigées; les problèmes critiques ou à haut risque jugés exploitables sont passés par les mécanismes de correction existants.

Un commentaire sur une demande de modification sert normalement à discuter d’un changement de code. Dans une étude de cas du gouvernement britannique, le commentaire lui-même constituait le déclencheur le plus important : un message spécialement construit pouvait lancer un ancien workflow automatisé associé à un dépôt qui soutenait un service numérique public majeur. Le workflow transmettait ensuite le contenu du commentaire à des paramètres de déploiement, puis à une étape de substitution d’environnement. Un utilisateur extérieur aurait ainsi pu faire exécuter cette entrée sur le serveur de compilation.

L’IA n’a ni certifié la faille ni autorisé son correctif. Les équipes ont essayé plusieurs méthodes : l’une utilisait une chaîne de six agents dont chaque étape contestait les résultats précédents; une autre partait d’outils déterministes, puis demandait à des modèles d’examiner et de trier les pistes. Pour le workflow décrit, une personne a vérifié les lignes concernées, confirmé que l’exposition était réelle et traité les faux positifs. Le rapport dit que les agents produisaient des pistes plus vite que les humains ne pouvaient les valider.

Le résultat utile se trouvait dans le passage vers l’examen de sécurité et la correction, pas dans le nombre brut de sorties machine.

Il s’agit d’un chemin vers l’exécution de code, pas du récit d’une attaque. L’étude publiée en juin indique que le problème a été découvert puis corrigé, et que le gouvernement n’a trouvé aucun indice d’exploitation pour l’ensemble des constats de l’exercice. Il faut conserver les deux éléments. Une exposition grave ne devient pas anodine parce qu’aucune exploitation n’a été observée; mais on ne doit pas non plus parler d’intrusion lorsque la source dit qu’aucune n’a été constatée.

Le gouvernement étudie aussi la réponse aux incidents impliquant des agents d’IA et la manière d’identifier et de signaler les incidents graves ou les quasi-accidents. Ce sont des travaux en cours, pas une nouvelle obligation de déclaration créée par l’annonce. La faille documentée fournit un test pratique : conserver la trace d’une piste proposée, de sa confirmation humaine, du correctif autorisé et des éléments montrant qu’aucune compromission du service n’a été constatée.

L’annonce d’octobre ajoute un chiffre plus large et distinct : deux pilotes auraient identifié et traité plus de 1 000 vulnérabilités potentielles dans les systèmes du gouvernement. Elle ne fournit pas de dénominateur commun ni de rapprochement avec les 407 constats de l’étude de juin. Il ne faut pas additionner ces chiffres. La même annonce prévoit une deuxième phase avec davantage de ministères et de modèles, qui passerait des dépôts publics à des environnements fermés. La frontière opérationnelle change alors : il faut encadrer les autorisations d’accès, le code confidentiel et la conservation des preuves de revue.

Sources