Kiteworks Agent Marketplace
Quel assistant IA utilisez-vous ?
Note de synthèse

Première violation par agent IA en Espagne : l’enjeu pour vos agents

L’autorité espagnole de protection des données a reçu sa première notification de violation attribuée à un agent IA : ce qu’elle en dit, et ce qu’il faut vérifier dans vos propres agents.

  • Accès et partage
  • Gouvernance et conservation
  • GDPR

Une notification de violation reçue par l’autorité espagnole de protection des données décrit une attaque dans laquelle un agent IA a lui-même mené la reconnaissance et l’exploitation des failles. Les faits ne sont pas encore vérifiés, mais la leçon pour toute organisation qui utilise des agents sur ses fichiers métier n’en dépend pas : définir ce à quoi chaque agent peut accéder, et soumettre chaque action qui modifie quelque chose à la validation d’une personne.

Ce que rapporte l’AEPD

Le 14 septembre 2026, l’Agencia Española de Protección de Datos (AEPD) a publié un billet de blog consacré à la première notification qu’elle a reçue d’une violation de données personnelles qui « aurait été menée au moyen d’un agent d’intelligence artificielle ayant utilisé un modèle de langage bien connu ». D’après la notification, l’agent a recherché des vulnérabilités dans des fichiers génériques, puis a réussi à se connecter. Une fois à l’intérieur, il a cherché de lui-même des failles dans l’application, ce qui lui a permis de modifier des données personnelles et d’accéder à des factures. (Les citations de sources en espagnol figurant dans cette note sont traduites par nos soins.)

Trois précisions comptent autant que les faits eux-mêmes :

  • L’AEPD écrit que ces informations « proviennent de la notification présentée par l’organisation concernée » et qu’elles doivent encore être analysées. Elle ne nomme pas l’organisation, pas plus que le secteur ou le modèle.
  • Un tiers aurait utilisé l’agent comme instrument de l’attaque. Il ne s’agit pas de l’assistant d’une entreprise devenu incontrôlable.
  • L’AEPD souligne que le recours à un modèle donné ne signifie pas que ce modèle ou son fournisseur a été compromis, et qu’une seule notification ne suffit pas à établir une tendance statistique.

Pourquoi cela concerne les agents que vous utilisez

La plupart des organisations utiliseront des agents sur leurs propres fichiers, en toute légitimité, bien plus souvent qu’elles n’en affronteront un dans le rôle de l’attaquant. Les recommandations de l’AEPD valent pour les deux situations. Les mêmes fondamentaux restent déterminants, écrit-elle : « connaître les traitements, minimiser les données, limiter les accès, corriger les vulnérabilités, contrôler les fournisseurs et être prêts à réagir ». Elle avertit aussi qu’« un agent qui obtient un compte, une clé API ou un jeton doté de droits excessifs peut opérer à la vitesse d’une machine », et que la supervision humaine reste indispensable, mais qu’elle doit s’appuyer sur une détection et une réponse capables de suivre ce rythme.

C’est un argument sur les accès, pas sur les modèles. Un agent qui n’atteint que le dossier dont il a besoin, et qui ne peut rien modifier tant qu’une personne n’a pas donné son accord, limite les dégâts lorsque les contenus qu’il traite sont malveillants ou que ses identifiants fuitent.

Un test tiré du guide de l’AEPD

En février 2026, l’AEPD a publié un guide sur l’IA agentique du point de vue de la protection des données. Il reprend la « règle de 2 », une règle de cybersécurité formulée en 2021 pour le navigateur Chromium, puis adaptée aux agents IA par d’autres acteurs, dont Meta. Ses trois propriétés sont les suivantes : traiter des entrées non fiables, accéder à des informations sensibles et agir automatiquement. L’exemple du guide est un agent de messagerie qui réunit les trois, et le verdict est sans ambiguïté : « Nous aurions là une configuration d’agent qui ne devrait pas être permise. » Lorsqu’un agent traite des entrées non fiables et accède à des données sensibles, précise le guide, toute action automatique ayant un effet à l’intérieur ou à l’extérieur de l’organisation doit être empêchée en l’absence de supervision humaine. L’AEPD présente elle-même cette règle comme un minimum et un point de départ pour l’analyse, et non comme une évaluation complète en matière de protection des données.

Appliquez-la à un agent documentaire. Les fichiers qui arrivent de l’extérieur de l’organisation sont des entrées non fiables : un document peut contenir des instructions destinées au modèle. Le dossier que lit l’agent peut contenir des données personnelles. La propriété à supprimer est donc la troisième : la capacité d’agir seul.

Comment les agents du Marketplace se situent face à ce test

Les agents du Marketplace s’exécutent dans Claude via le connecteur Kiteworks, sur un dossier que vous choisissez, avec les autorisations de connecteur de la personne qui les utilise. La plupart se contentent de lire et de produire un rapport. Lorsqu’un agent écrit, ses instructions exigent d’abord une confirmation. Sharing Auditor n’enregistre un rapport qu’après que vous avez confirmé l’emplacement, et ne dispose d’aucun outil pour modifier un partage. Invoice Organizer ne renomme des fichiers qu’après que vous avez approuvé les noms proposés. Avant un projet pilote, lisez chaque fiche pour savoir ce que l’agent lit, ce qu’il peut écrire et ce qu’il ne peut pas voir.

Deux agents aident en outre à appliquer les fondamentaux que l’AEPD cite en premier. Sharing Auditor montre quelles arborescences de dossiers d’un périmètre sont partagées et où commence le partage : vous savez ainsi ce qu’un agent, ou n’importe qui d’autre, pourrait atteindre par ce biais. Sensitive Content Scanner repère dans un dossier les termes sensibles et les données personnelles courantes, ce qui vous indique quels périmètres tenir à l’écart des agents qui traitent des documents externes. Tous deux produisent un rapport ; aucun ne modifie un partage ou un fichier.

Questions à poser avant de connecter un agent

  • Quels dossiers l’agent lira-t-il, et contiennent-ils des données personnelles dont il n’a pas besoin ?
  • D’où proviennent ses entrées, et une partie a-t-elle pu être rédigée par un tiers extérieur ?
  • Que peut-il modifier, et chaque modification attend-elle l’approbation d’une personne nommément désignée ?
  • À qui appartiennent les identifiants qu’il utilise, et en combien de temps pourriez-vous les révoquer ?
  • Votre analyse de risques intègre-t-elle désormais les attaques assistées par l’IA, comme l’AEPD invite les responsables du traitement à le faire ?
  • Qui examine le rapport de l’agent, et où la décision est-elle consignée ?

Si vous souhaitez confronter un agent à ces questions avant un projet pilote, écrivez à sales@kiteworks.com ou prenez contact avec nous. Inutile d’avoir configuré Claude ou MCP pour nous solliciter. Consultez le catalogue des agents pour connaître les limites déclarées de chacun.

Sources

  1. Primera notificación de una brecha de datos personales causada por un ataque ejecutado mediante un agente de IA · Agencia Española de Protección de Datos (AEPD) ·
  2. Inteligencia Artificial Agéntica desde la perspectiva de protección de datos · Agencia Española de Protección de Datos (AEPD) ·
  3. Agents Rule of Two: A Practical Approach to AI Agent Security · Meta AI ·