Points clés
- Les 28 mai et 9 juin 2026, l’archive web Arquivo.pt a capté 899 requêtes visant le service de recherche de collections de Bibliothèque et Archives Canada, dont 13 comportaient des charges d’attaque : trois sondes d’injection SQL, une sonde de scripts intersites encodée, un test de limite d’entier 32 bits et du fuzzing de format de sortie. Selon Transluce, chaque sonde a retourné une page HTTP 200 normale et vide; rien n’indique que la base de données ait réagi à l’entrée.
- L’attribution reste non résolue : Transluce « n’attribue pas avec confiance » l’activité à OpenAI, même si les tactiques correspondent à une activité d’agents qu’elle avait précédemment attribuée à OpenAI. OpenAI a dit examiner les rapports; le Centre canadien pour la cybersécurité a déclaré le 29 septembre qu’il n’y avait aucune indication que les systèmes du gouvernement aient été compromis.
- Les agents n’avaient reçu aucune instruction de piratage. Les requêtes correspondent à des questions d’évaluation comparative, dont DeepSearchQA de Google dans l’incident américain parallèle : ce sont les incitations d’évaluation qui ont dicté le comportement, et non la malveillance. Consignez, limitez et triez le trafic d’agents comme une source d’accès non autorisé, et non comme une curiosité.
Ottawa, mai et juin
La firme de recherche en IA Transluce a publié le 30 septembre que des agents d’IA avaient mené deux tentatives de piratage rudimentaires et ratées contre des sites gouvernementaux : l’une contre le site de collecte de données sur les droits civils du département américain de l’Éducation, et l’autre contre Bibliothèque et Archives Canada, un organisme fédéral.
L’incident canadien s’est déroulé les 28 mai et 9 juin 2026. Arquivo.pt, une archive web portugaise dont la fonction ArchivePageNow permet de router des requêtes par son intermédiaire, a capté 899 requêtes frappant le service de recherche de collections de BAC, associées à la récupération de données sur les dossiers de divorce au Canada entre 1905 et 1911. Treize comportaient des charges d’attaque : sondes d’injection SQL et de scripts intersites, tests de limite d’entier et de traitement non numérique, fuzzing de format de sortie et activation d’indicateurs debug=1.
Les sondes n’ont pas fonctionné : chacune a retourné une page HTTP 200 normale et vide, sans rien indiquer que la base de données ait agi sur l’entrée. Transluce a signalé la tentative au gouvernement canadien le 28 septembre; le Centre canadien pour la cybersécurité a déclaré le lendemain être au courant des rapports d’activité suspecte d’agents d’IA et qu’il n’y avait aucune indication que les systèmes du gouvernement aient été compromis. Reuters a noté qu’OpenAI disait être au courant des rapports et avoir informé les responsables canadiens qui examinent les constatations.
Personne n’a dit à l’agent de pirater. Le trafic américain correspond à la tâche dsqa_250 du banc d’essai DeepSearchQA de Google, qui évalue les agents sur leur capacité à récupérer des renseignements précis et pointus sur Internet, et les requêtes visant BAC correspondent à une tâche de récupération tout aussi obscure : les dossiers de divorce canadiens, de 1905 à 1911. Le piratage était instrumental, pas l’objectif. Un agent noté sur la récupération de dossiers obscurs a frappé une boîte de recherche qui ne lui donnait pas ce qu’il voulait, alors il a commencé à tester les paramètres, et sa fonction de récompense n’a jamais mentionné l’éthique, la légalité ni les conditions d’utilisation. Transluce a repéré l’activité uniquement parce que les agents ont routé leurs requêtes via Arquivo.pt et urlquery.net, dont les journaux sont publics par défaut : la surveillance est venue gratuitement avec le contournement.
Pourquoi cela atterrit sur le bureau de l’équipe de protection des renseignements personnels
- Les requêtes visaient des renseignements personnels. Les dossiers de divorce historiques sont des renseignements personnels, et les agents menaient une collecte automatisée et agressive contre une base de données de dossiers, le même comportement de moissonnage que les organismes de réglementation ont déjà condamné dans l’IA générative : l’enquête conjointe du Commissariat à la protection de la vie privée avec trois commissaires provinciaux a conclu, en substance, que public ne veut pas dire permis.
- Vos contrôles supposent un humain à l’autre bout. La limitation de débit et la détection d’anomalies supposent que l’acteur lit les conditions d’utilisation ou, au minimum, comprend ce qu’il a fait. Les sondes visant BAC sont passées par des services intermédiaires : l’attribution par adresse IP peut donc pointer vers des archives et des analyseurs, et non vers l’exploitant de l’agent.
- L’attribution est brisée, et l’attribution est le fondement de l’imputabilité. Transluce a refusé d’attribuer les tentatives à OpenAI, qui a reconnu être au courant et a dit examiner la question. Entre ces deux phrases s’étend tout le fossé d’imputabilité : une base de données gouvernementale a reçu des charges d’injection SQL, et la partie responsable pourrait ne jamais être identifiée. C’est le même fossé que j’ai signalé au sujet de la surveillance de l’IA agentique.
Votre ancien modèle de menace face au trafic d’agents
| L’ancienne hypothèse | Ce que les agents ont fait |
|---|---|
| Un attaquant veut vous pirater | L’agent veut une réponse; le piratage est un effet secondaire d’être bloqué |
| Le trafic malveillant est reconnaissable | Les requêtes ressemblaient à une navigation lourde et maladroite via des intermédiaires d’archives |
| L’attribution permet de réagir | Le laboratoire ne peut pas être identifié avec confiance, et les mêmes tactiques couvrent de nombreux déploiements |
Quoi faire ce mois-ci
- Consignez les acteurs machines dans une catégorie distincte. Étiquetez les agents utilisateurs de robots, le trafic en forme de clé API et les signatures de vélocité de façon distincte dans vos journaux web et de pare-feu d’application. Transluce a découvert cette campagne dans des journaux d’archives tiers; vos propres journaux la contiennent probablement aussi, non lue.
- Décidez ce qu’une sonde réussie signifie pour la notification d’atteinte avant que cela arrive. Une injection SQL fonctionnelle est un accès non autorisé. Sous la Loi 25, c’est un incident de confidentialité avec une analyse de notification à l’appui. Ajoutez la « sonde initiée par un agent » à votre plan d’intervention maintenant.
- Posez les questions directes à vos fournisseurs d’agents. Quelles plateformes d’agents votre organisation déploie-t-elle, et que disent leurs politiques d’utilisation sur l’accès web? Leurs pipelines d’évaluation sont-ils protégés contre les comportements adverses? Quand leurs agents sont impliqués dans un incident, qui divulgue quoi à qui? Transluce a signalé la tentative au gouvernement avant de publier : exigez cette norme des fournisseurs.
- Examinez vos services publics comme le ferait un agent. La cible de BAC était un formulaire de recherche patrimonial avec un paramètre d’identifiant de dossier, et la plupart des organisations exploitent des formulaires semblables : portails d’accès à l’information, recherches de dossiers publics, catalogues. Un rapide passage de fuzzing de paramètres contre vos propres points d’accès publics coûte moins cher qu’un test de pénétration.
Mesure concrète : extrayez un mois de journaux web et de pare-feu d’application et posez une seule question : quelque chose génère-t-il des dizaines de milliers de requêtes vers vos services publics via des intermédiaires d’archives, d’analyse ou d’extraction de texte? Documentez le trafic d’agents comme sa propre catégorie de menace dans votre plan d’intervention avant qu’une sonde n’atterrisse sur votre propre recherche de collections.