← Le blog d'Origin Labs

Actus IA

Une attaque menée par une IA seule, selon l'AEPD : les verrous à poser

Le régulateur espagnol des données, l'AEPD, a reçu sa première notification de brèche exécutée par un agent IA capable d'agir de façon quasi autonome : l'agent a cherché des failles, réussi une connexion, puis a modifié des données personnelles et consulté des factures sans qu'un opérateur humain le guide pas à pas. Pour une PME, la nouveauté n'est pas un nouveau type d'attaque, c'est une attaque qui ne se fatigue pas et n'attend personne : les verrous sont les classiques, simplement devenus non négociables.

L'entreprise victime n'est pas nommée, le modèle utilisé non plus, et l'agence souligne elle-même que l'information vient de la notification de l'entreprise et reste à analyser. Le cas est donc documenté avec prudence, mais il est documenté par un régulateur : c'est ce qui change.

« Con carácter previo a ningún tipo de conclusión, hay que señalar que la información disponible procede de la notificación presentada por la organización afectada y deberá ser objeto del correspondiente análisis. »

Francisco Pérez Bes, adjoint de l'AEPD, dans le billet officiel de l'agence du 14 septembre 2026. En français : avant toute conclusion, l'information disponible vient de la notification de l'entreprise victime et devra être analysée.

Devant l'atelier d'une PME au bord d'un lac de montagne, une petite machine autonome à roues teste les serrures d'une rangée d'armoires à dossiers ; l'une d'elles, entrouverte, luit en rouge pendant qu'une main humaine retient le levier de coupure

L'essentiel en cinq points

  • L'AEPD a reçu sa première notification de brèche de données personnelles dont l'exécution est attribuée à un agent IA, un logiciel qui enchaîne des actions presque sans pilote humain, comme l'écrit l'agence elle-même le 14 septembre 2026, repris par Europa Press deux jours plus tard.
  • Selon le récit notifié, l'agent a d'abord cherché des vulnérabilités, ces défauts d'un logiciel qui ouvrent une porte non prévue, dans des fichiers génériques, et réussi un « login », une connexion à un compte. Une fois dans le système, il a continué seul : repérer d'autres failles dans l'application, modifier des données personnelles, accéder à des factures.
  • L'agence parle d'un « changement qualitatif » : un agent peut recevoir un objectif, planifier des tâches intermédiaires, utiliser des outils, exécuter du code, consulter des sources, interpréter les résultats et modifier son action selon ce qu'il trouve, définition reprise du billet de l'AEPD et relayée par Xataka.
  • Le modèle de langage utilisé est « connu » mais non nommé, et l'AEPD précise que son usage ne signifie ni que le modèle a été compromis, ni qu'il a été conçu pour attaquer, déclaration reprise par BleepingComputer.
  • Pour une PME française, la conséquence pratique tient en deux réflexes : les verrous d'hygiène deviennent urgents parce que l'attaquant ne dort pas, et le réflexe notification existe ici aussi : une violation qui présente un risque pour les personnes se signale à la CNIL dans les meilleurs délais, 72 heures si possible, selon la procédure officielle de la CNIL.

Ce que l'attaque a réellement fait, selon le régulateur

Le récit le plus fiable est celui du billet de l'AEPD, repris par la presse espagnole. Trois étapes se lisent clairement.

D'abord, la recherche. L'agent a exploré des fichiers génériques à la recherche de vulnérabilités. Puis la connexion : il a obtenu un login valide. Point important d'honnêteté du dossier : on ne sait pas comment ces identifiants ont été obtenus, et l'AEPD ne l'explique pas. Enfin, le travail autonome : à l'intérieur, l'agent a cherché d'autres failles dans l'application, en a trouvé au moins une, a modifié des données personnelles et a consulté des factures.

La phrase qui compte pour un dirigeant est celle de la méthode : l'agent « peut recevoir un objectif, planifier des tâches intermédiaires, utiliser des outils, exécuter du code, consulter des sources, interpréter les résultats et modifier son action de façon autonome selon ce qu'il trouve », écrit l'AEPD dans son billet du 14 septembre (notre traduction ; ABC le cite aussi en espagnol). Ce n'est plus un humain qui tape des commandes : c'est un logiciel qui décide du prochain essai.

Pourquoi une PME doit s'en soucier alors que le cas est unique

Deux précautions d'abord. C'est une seule notification, et Pérez Bes prévient dans son billet qu'elle « ne permet pas d'affirmer une tendance statistique » (notre traduction ; phrase reprise par Estrella Digital). Et l'entreprise victime comme le modèle restent anonymes : impossible de mesurer la difficulté réelle de l'attaque.

Mais le signal structurel est net. Une attaque humaine a un rythme : l'attaquant dort, se trompe, change de cible quand ça résiste. Un agent n'a pas ce rythme. Il teste les entrées en continu, explore tout ce que le compte compromis peut toucher et ne se lasse pas d'un dossier ennuyeux. Concrètement, les défauts qu'une petite structure laisse vivre depuis des années, un compte partagé, une application non mise à jour, un accès trop large, passent de « risque théorique » à « trouvé en quelques heures ».

Il y a aussi l'envers du décor : les mêmes agents entrent dans vos outils. Un assistant IA branché sur votre base clients avec des droits trop larges présente, en miroir, le même risque de privilège excessif. Notre guide sur la sécurité des agents IA branchés à la base clients détaille cette face du problème.

Les cinq verrous à poser cette semaine

Chaque verrou répond à une étape précise du récit espagnol. Aucun ne demande un RSSI, un responsable de la sécurité des systèmes d'information.

  1. Un second facteur partout, et zéro mot de passe partagé. L'attaque a commencé par un login. Le double facteur (MFA, authentification à plusieurs facteurs), ce code envoyé sur un second appareil, bloque la plupart des identifiants volés. Vérifiez les comptes communs : un mot de passe partagé par cinq personnes est un login qui ne protège rien.
  2. Des accès au strict nécessaire. Une fois connecté, l'agent a cherché ce que le compte pouvait toucher. L'AEPD prévient elle-même du danger d'un compte, d'une clé API ou d'un jeton, ces sésames techniques que les logiciels se présentent entre eux, aux permissions trop larges, comme le résume Xataka. Passez en revue qui peut lire quoi : factures, données clients, exports. Un compte commercial n'a pas à ouvrir la comptabilité.
  3. Les applications exposées à jour. L'agent a trouvé des vulnérabilités dans des fichiers génériques et dans l'application. La mise à jour qui traîne est précisément la porte qu'il teste. Listez vos outils en ligne : site, boutique, logiciel de facturation, espace de partage. Ce qui est obsolète se corrige ou se ferme.
  4. Des journaux que quelqu'un lit. Une exploration autonome laisse des traces : connexions inhabituelles, lectures massives, horaires impossibles. Activez les alertes de connexion de vos outils principaux et nommez la personne qui les reçoit. Une alerte lue le lendemain vaut mieux qu'un journal découvert après la brèche.
  5. Un réflexe brèche écrit à l'avance. En France comme en Espagne, une violation de données personnelles qui présente un risque pour les personnes se notifie à l'autorité, la CNIL, dans les meilleurs délais et 72 heures si possible, selon la procédure officielle ; les autres violations sont documentées en interne. Écrivez à l'avance qui prévient, qui coupe les accès, où sont les sauvegardes et quel est le contact de votre assureur si vous en avez un.

Apport Origin : pour prioriser sans jargon, voici la grille que nous utilisons en accompagnement : chaque verrou se note sur deux axes, l'effort demandé et l'étape du récit qu'il bloque.

Verrou Effort Étape du récit bloquée
Double facteur et mots de passe uniques une heure le login
Tri des accès au strict nécessaire un jour le déplacement latéral, cette exploration de proche en proche à l'intérieur du système
Mises à jour et journaux lus une semaine la recherche de failles
Réflexe brèche écrit une heure rien : il prépare le jour où le reste a échoué, le seul poste qu'on peut reporter sans se mentir

Ce que le cas ne permet pas de conclure

Trois limites honnêtes. On ne sait pas comment les identifiants ont été obtenus : hameçonnage classique (phishing), fuite antérieure, ou trouvés dans les fichiers explorés, le récit ne le dit pas. On ne sait pas non plus à quel point le système était défendu : modifier des données dans une application sans protection n'est pas la même prouesse que traverser une infrastructure surveillée. Et une notification n'est pas une tendance : l'agent pourrait rester un cas isolé. Mais les verrous ci-dessus se justifient de toute façon, attaque autonome ou pas ; l'actualité ne fait que retirer l'excuse du délai.

Un exemple fictif : la quincaillerie du lundi matin

Imaginons une PME fictive de douze personnes, « Quincaillerie Moderne », qui lit cette dépêche lundi. Le dirigeant passe une heure : double facteur sur la boîte mail et le logiciel de facturation, et le compte « compta » partagé par trois personnes devient trois comptes. Mardi, il liste les accès : l'assistant commercial n'a plus besoin d'ouvrir les exports fournisseurs. Mercredi, son prestataire met à jour le site et la boutique. Jeudi, il active les alertes de connexion sur les deux outils critiques. Vendredi, il écrit sur une page qui prévient la CNIL, qui coupe les comptes et où dorment les sauvegardes. Aucun de ces gestes ne suppose un spécialiste sécurité ; tous ferment une étape précise du récit espagnol.

Le contexte assurance, sans inflation

Pendant ce temps, la couverture cyber des petites entreprises recule plutôt qu'elle ne progresse. Le dixième rapport annuel de l'assureur Hiscox, publié le 15 septembre 2026 et mené par Wakefield Research auprès de 6 800 responsables cybersécurité d'organisations de moins de 250 salariés dans dix pays, mesure que la part des TPE/PME françaises détenant une police cyber dédiée est passée de 33,6 % à 27,6 % en un an, et que 45 % des entreprises françaises interrogées ne disposent d'aucune couverture contre le risque cyber, contre 39 % en 2025 ; parmi elles, 12 % n'envisagent même pas d'en souscrire, contre 9 % un an plus tôt, comme le synthétise Le Monde Informatique. Détail utile : seuls 69 % des assurés français disent que leur contrat couvre les risques liés à l'IA. L'assurance ne remplace pas les verrous ; elle absorbe le résidu, à condition de vérifier ce que le contrat couvre vraiment. Pour préparer cet échange, notre guide sur les questions à poser au courtier avant d'assurer un agent IA donne la fiche de scénarios à faire remplir.

Le premier verrou tient en une heure : commencez par le double facteur et la fin des mots de passe partagés, puis reprenez la grille ci-dessus pour le reste de la semaine. Côté outils internes, notre guide sur la sécurité des agents IA branchés à la base clients détaille l'architecture défensive, et notre article sur les questions à poser au courtier avant d'assurer un agent IA prépare le volet assurance.

FAQ

Une IA peut-elle vraiment pirater seule une entreprise ?

C'est ce que la première notification reçue par l'AEPD décrit : un agent a cherché des vulnérabilités, réussi une connexion puis a poursuivi seul l'exploration jusqu'à modifier des données et consulter des factures. Le régulateur précise que le récit vient de l'entreprise victime et reste à analyser, et qu'il ne permet pas de conclure à une tendance. C'est un cas documenté, pas encore un schéma.

Le modèle d'IA utilisé est-il accusé d'être malveillant ?

Non. L'AEPD indique qu'un modèle de langage « connu » a été utilisé, sans le nommer, et précise que cela ne signifie ni que le modèle ou l'infrastructure de son fournisseur ont été compromis, ni que l'outil a été conçu pour des activités malveillantes. L'outil a été instrumentalisé ; c'est l'usage qui est en cause.

Que doit faire concrètement une PME qui lit cette dépêche ?

Poser les verrous qui ferment les étapes du récit : double facteur et fin des mots de passe partagés contre le login, accès au strict nécessaire contre le déplacement latéral, cette exploration de proche en proche à l'intérieur du système, applications exposées à jour contre la recherche de failles, journaux lus par quelqu'un, et un réflexe brèche écrit avec la notification CNIL quand la violation présente un risque. Aucun n'exige un profil sécurité dédié.

Une attaque par IA change-t-elle mes obligations en cas de brèche ?

Non. Le canal de l'attaque ne change pas l'obligation : une violation de données personnelles qui présente un risque pour les droits et libertés des personnes se notifie à la CNIL dans les meilleurs délais, 72 heures si possible, tout retard devant être motivé ; les autres violations sont documentées en interne, et les personnes concernées sont prévenues si le risque est élevé. Ce qui change, c'est la vitesse à laquelle la brèche peut se produire ; d'où l'intérêt d'avoir le réflexe écrit avant, pas après.

Sources