Une autorité de protection des données vient de documenter un seuil que les responsables de la sécurité anticipaient sans encore pouvoir l’observer aussi directement. Le 14 septembre 2026, l’Agence espagnole de protection des données, l’AEPD, a annoncé avoir reçu la première notification, en Espagne, d’une violation de données personnelles dans laquelle un agent d’intelligence artificielle aurait exécuté plusieurs phases de l’attaque. Selon les informations communiquées, l’agent aurait accédé au système, recherché de manière autonome des vulnérabilités applicatives, modifié des données personnelles et consulté des factures. L’incident reste en cours d’analyse : l’organisation touchée et le modèle utilisé n’ont pas été identifiés publiquement, et l’autorité n’a pas encore rendu de conclusion définitive.
Cette prudence factuelle est indispensable. Il ne s’agit pas de présenter une IA devenue spontanément hostile. Un tiers aurait utilisé un agent comme instrument opérationnel. Le modèle et l’infrastructure de son fournisseur ne sont pas, à ce stade, considérés comme compromis, pas plus que l’outil n’aurait été conçu pour mener des activités malveillantes. Le fait nouveau tient ailleurs : une partie de la boucle d’attaque aurait été confiée à un système capable d’observer un environnement, de choisir une action puis d’adapter la suivante en fonction du résultat obtenu.
L’enjeu n’est donc plus seulement de savoir si l’IA aide un attaquant à rédiger un courriel de phishing ou à produire un script. Il faut désormais déterminer si les organisations savent détecter, ralentir et interrompre une séquence d’attaque qui peut progresser plus vite que leurs propres processus de réponse.
Ce que l’AEPD a annoncé et ce qui reste à établir
Dans sa communication officielle, l’AEPD explique que la notification provient de l’organisation affectée. D’après les éléments déclarés à l’autorité, un agent utilisant un modèle de langage connu aurait réussi à se connecter au système avant de rechercher des faiblesses dans l’application. Après avoir identifié une vulnérabilité, il aurait pu modifier des informations personnelles et consulter des données de facturation.
Plusieurs distinctions doivent être conservées.
- Il s’agit du premier cas notifié à l’AEPD, et non de la preuve qu’aucune attaque comparable n’a eu lieu auparavant dans le monde.
- L’incident est signalé et fait encore l’objet d’un examen ; le degré exact d’autonomie de l’agent n’est pas publiquement établi.
- L’IA n’aurait pas créé seule l’objectif de l’attaque. Un acteur humain aurait sélectionné la cible, fourni l’intention initiale ou configuré l’environnement d’exécution.
- L’utilisation d’un modèle ne signifie pas que son fournisseur a été piraté ou qu’il a autorisé l’opération.
- Les informations disponibles ne permettent pas encore de déterminer le vecteur initial, la durée de l’intrusion, le volume de données concerné ni les contrôles qui ont échoué.
Ces limites ne diminuent pas l’importance de l’événement. Elles empêchent simplement de confondre autonomie opérationnelle, intention et responsabilité. Un agent peut exécuter et adapter des actions sans devenir pour autant l’auteur juridique ou moral de l’attaque. La responsabilité ne se déplace pas vers la machine : elle doit être appréciée, selon les faits et les règles applicables, au regard du rôle des personnes et des organisations impliquées.
De l’assistance à l’orchestration de la chaîne d’attaque
Une cyberattaque classique comporte déjà une succession d’étapes : reconnaissance, obtention d’un accès, découverte de l’environnement, exploitation, élévation de privilèges, collecte puis exfiltration. L’IA générative a d’abord accéléré chaque étape séparément. Elle pouvait aider à analyser une documentation, traduire un message, corriger du code ou interpréter le résultat d’un scanner.
L’agent ajoute une boucle : objectif, action, observation, adaptation. Il ne se contente plus de recommander la prochaine commande à un opérateur. Lorsqu’il dispose d’outils, d’un accès réseau et d’identifiants, il peut enchaîner des opérations, interpréter les réponses du système et modifier sa trajectoire.
Le rapport de renseignement sur les menaces publié par Anthropic en septembre 2026 décrit justement ce passage de l’assistant à l’orchestrateur. Les opérations observées ne reposaient plus seulement sur des échanges ponctuels avec un chatbot. Des acteurs étatiques, criminels ou politiquement motivés ont utilisé des flux agentiques pour intervenir sur plusieurs étapes de la chaîne d’attaque. Anthropic souligne que le principal effet de l’IA ne réside pas nécessairement dans l’invention de vulnérabilités entièrement nouvelles, mais dans l’augmentation de la vitesse, de l’échelle et de la profondeur auxquelles des techniques connues peuvent être appliquées.
Le cas espagnol donne désormais une traduction concrète à cette évolution. La menace ne change pas toujours de nature : accès compromis, vulnérabilité applicative, modification et consultation de données existaient avant les agents. En revanche, leur combinaison peut devenir plus rapide, plus persistante et moins dépendante d’un opérateur expert présent à chaque étape.
DEVFORMA avait déjà analysé cette évolution dans ses articles consacrés aux attaquants non humains et au cloisonnement des systèmes autonomes. Le nouveau signalement déplace maintenant la réflexion du laboratoire vers la production : comment répondre lorsqu’un agent n’est plus seulement évalué dans une sandbox, mais utilisé contre un système contenant de vraies données personnelles ?
L’identité devient le premier champ de bataille
Le point le plus instructif du signalement n’est peut-être pas la vulnérabilité découverte par l’agent. C’est le fait qu’il aurait d’abord réussi à se connecter au système. Une attaque agentique peut exploiter une faille, mais elle peut aussi avancer au moyen d’éléments parfaitement légitimes : compte utilisateur compromis, jeton d’API, session cloud, secret exposé, compte de service ou accès prestataire.
Cette situation fragilise les dispositifs qui cherchent surtout un logiciel malveillant ou une signature connue. Une requête effectuée avec un identifiant valide peut paraître autorisée lorsqu’elle est examinée isolément. C’est la séquence qui devient anormale : connexion inhabituelle, énumération rapide de ressources, tests successifs de paramètres, consultation de données éloignées de l’usage habituel du compte, puis modification en volume.
Comme l’explique notre analyse sur l’Identity Security, une identité ne doit plus être considérée comme fiable du seul fait qu’elle a franchi l’authentification. Pour chaque compte humain, technique ou agentique, l’organisation doit pouvoir répondre à cinq questions : qui ou quoi agit, au nom de qui, avec quels droits, dans quel contexte et selon quel comportement attendu ?
L’arrivée des agents renforce plusieurs exigences :
- attribuer une identité distincte à chaque service ou agent au lieu de partager des comptes génériques ;
- utiliser des jetons courts, révocables et limités à une tâche ;
- appliquer le moindre privilège aux données, aux outils et aux actions, pas uniquement aux applications ;
- détecter les écarts de comportement et la combinaison d’événements, plutôt qu’une action isolée ;
- séparer les droits de lecture, de modification, d’exportation et d’administration ;
- imposer une validation supplémentaire lors d’un changement de périmètre ou d’une opération difficilement réversible.
Il faut également distinguer deux risques. Dans le cas signalé en Espagne, un tiers aurait placé un agent au service de l’attaque contre une organisation. Dans un autre scénario, l’agent légitime de l’entreprise peut être détourné par une instruction cachée dans un courriel, un document ou une page web. Cette seconde menace, détaillée dans notre article sur l’injection indirecte d’instructions, appelle des contrôles complémentaires sur les sources, les connecteurs et les validations humaines.
La réponse à incident doit fonctionner à la vitesse de l’attaque
Les plans de réponse à incident restent souvent organisés autour d’un rythme humain : une alerte est remontée, un analyste la qualifie, un responsable décide, une équipe révoque les accès, puis les métiers et le DPO évaluent les conséquences. Ce modèle reste nécessaire, mais il devient insuffisant lorsque l’attaquant peut automatiser la reconnaissance, interpréter les résultats et relancer immédiatement une nouvelle action.
La question centrale devient celle de la latence défensive. Combien de temps s’écoule entre le premier signal faible et la suspension effective de l’identité ? Entre la détection d’une consultation anormale et le blocage des exportations ? Entre une modification de données et la conservation des preuves nécessaires pour comprendre son origine ?
Une réponse adaptée aux attaques agentiques doit combiner décision humaine et confinement automatique. Les mesures les plus urgentes ne nécessitent pas d’identifier précisément le modèle utilisé. Elles consistent à limiter l’impact pendant que l’analyse se poursuit :
- suspendre ou réduire automatiquement les privilèges d’une identité présentant une séquence anormale ;
- révoquer les sessions et les jetons sans attendre la fin de l’investigation ;
- désactiver temporairement les fonctions d’écriture, d’exportation ou d’administration ;
- appliquer des limites de fréquence, de volume, de durée et de coût aux API sensibles ;
- isoler l’actif concerné tout en préservant ses journaux et les traces externes ;
- déclencher une escalade humaine lorsque plusieurs signaux faibles forment une trajectoire d’attaque.
La norme ISO/IEC 27035 fournit un cadre de préparation, de détection, d’évaluation, de réponse et de retour d’expérience. Dans un contexte agentique, ce processus doit intégrer des scénarios où la vitesse de progression dépasse la capacité de traitement manuel. Le playbook ne peut donc pas se limiter à une liste de contacts : il doit préciser les seuils de confinement automatique, les droits de décision, les actifs à isoler et les preuves à conserver.
RGPD, ISO 27001, ISO 42001 : des responsabilités différentes mais complémentaires
L’emploi d’une IA dans l’attaque ne modifie pas la définition d’une violation de données personnelles. Dès lors que la confidentialité, l’intégrité ou la disponibilité de données personnelles est compromise, le responsable de traitement doit qualifier l’incident au regard du RGPD. Lorsque la violation est susceptible d’engendrer un risque pour les droits et libertés, l’article 33 prévoit une notification à l’autorité de contrôle dans les meilleurs délais et, si possible, dans les 72 heures suivant le moment où l’organisation en a pris connaissance. En présence d’un risque élevé, l’article 34 peut également imposer une communication aux personnes concernées.
L’organisation n’a pas besoin de connaître le nom du modèle, son fournisseur ou le niveau exact d’autonomie avant d’engager cette analyse. Attendre une attribution parfaite ferait perdre un temps précieux. Les premières questions portent sur les données concernées, le nombre de personnes, les conséquences possibles, la durée de l’exposition et les mesures déjà prises.
L’AI Act ne s’applique pas automatiquement à toute violation parce qu’un agent IA a été utilisé par l’attaquant. Les obligations dépendent du système concerné, de sa classification et du rôle de chaque acteur. En revanche, lorsqu’une organisation développe ou déploie elle-même des systèmes d’IA, le règlement renforce l’importance de la gestion des risques, de la journalisation, de la supervision humaine, de la robustesse et de la cybersécurité dans les cas prévus par le texte.
Les normes de management permettent de traduire ces responsabilités en dispositif opérationnel :
| Enjeu | Contrôle prioritaire | Preuve attendue | Cadre principal |
|---|---|---|---|
| Identités et privilèges | Identités distinctes, moindre privilège, jetons courts, révocation rapide | Matrice d’habilitation, revues d’accès, journaux d’authentification | ISO/IEC 27001 |
| Vulnérabilités et applications | Inventaire, tests, correctifs, segmentation, validation des entrées et contrôle des API | Rapports de tests, tickets de correction, cartographie des flux | ISO/IEC 27001 et ISO/IEC 27032 |
| Agents utilisés par l’organisation | Inventaire, niveau d’autonomie, limites d’action, supervision et suivi des fournisseurs | Registre des systèmes IA, analyse d’impacts, règles d’usage, rapports de surveillance | ISO/IEC 42001 |
| Gestion des risques IA | Scénarios de détournement, usage malveillant, erreurs, dépendances et impacts | Registre des risques, critères d’acceptation, plans de traitement | ISO/IEC 23894 et NIST AI RMF |
| Réponse et notification | Playbooks, seuils d’escalade, confinement, conservation de la preuve et communication | Chronologie de l’incident, décisions, notification, retour d’expérience | ISO/IEC 27035 et RGPD |
Cette articulation évite deux erreurs. La première consisterait à traiter l’attaque comme un sujet exclusivement lié au modèle, alors que l’accès initial, les identités, l’application et les données relèvent d’abord de la sécurité de l’information. La seconde serait de traiter les agents déployés en interne comme de simples logiciels, sans gouverner leur finalité, leur autonomie, leurs impacts et les tiers dont ils dépendent.
Notre article consacré à l’intégration de l’IA au périmètre du SMSI montre précisément pourquoi le SMSI doit désormais inventorier les modèles, les agents, leurs identités, leurs connecteurs et leurs flux. Le SMIA fondé sur ISO/IEC 42001 complète cette approche en organisant la gouvernance propre aux systèmes d’IA.
Une asymétrie de temps plus qu’une menace entièrement nouvelle
Le premier enseignement du signalement espagnol n’est pas que l’intelligence artificielle aurait inventé une nouvelle forme de violation de données. Les accès compromis, les vulnérabilités applicatives et les consultations illicites sont des risques connus. Le changement réside dans la capacité à les enchaîner, les adapter et les répéter à une vitesse croissante, avec moins d’expertise humaine mobilisée à chaque étape.
Une organisation peut donc disposer de bonnes politiques tout en restant vulnérable si ses contrôles nécessitent plusieurs heures pour produire une décision. Face à un agent, le temps de détection, le temps de révocation et le temps de confinement deviennent des indicateurs de gouvernance au même titre que le nombre de vulnérabilités ou le taux de conformité.
La question à poser au RSSI, au DPO et au responsable IA n’est plus seulement : « pouvons-nous empêcher une cyberattaque ? » Elle devient : « pouvons-nous reconnaître et interrompre une boucle d’attaque automatisée avant qu’elle ne transforme un accès initial en violation de données ? »
DEVFORMA accompagne les organisations dans cette convergence entre gouvernance de l’IA, sécurité de l’information et réponse aux incidents. La formation ISO/IEC 42001 Lead Implementer permet de structurer et piloter un système de management de l’IA. La formation Lead AI Risk Manager approfondit l’identification et le traitement des risques propres aux systèmes d’IA. Les formations ISO/IEC 27001 Lead Implementer et ISO/IEC 27035 Lead Incident Manager apportent les cadres nécessaires pour sécuriser le système d’information et organiser une réponse démontrable aux incidents.
Pour construire un dispositif adapté à vos agents, à vos données et à vos obligations, contactez DEVFORMA.
FAQ
S’agit-il de la première cyberattaque mondiale menée par un agent IA ?
Non. L’AEPD indique avoir reçu la première notification de ce type en Espagne. D’autres opérations assistées ou orchestrées par l’IA ont déjà été documentées. Il serait donc inexact de présenter ce cas comme la première cyberattaque agentique mondiale.
L’agent a-t-il agi sans aucune intervention humaine ?
Les informations disponibles indiquent qu’un tiers aurait utilisé l’agent pour enchaîner plusieurs étapes avec une autonomie importante. Elles ne démontrent pas une absence totale d’intervention humaine : la cible, l’objectif initial et l’environnement ont nécessairement été définis ou fournis par un opérateur.
Le modèle d’IA ou son fournisseur ont-ils été compromis ?
L’AEPD précise que l’utilisation d’un modèle connu ne signifie pas 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.
Quelle mesure faut-il prioriser face aux attaques agentiques ?
La priorité est de réduire l’effet maximal d’un accès initial : moindre privilège, séparation des capacités de lecture et d’écriture, jetons révocables, journalisation centralisée, détection comportementale et confinement rapide. Aucun filtre appliqué au modèle ne peut remplacer ces contrôles d’architecture.
