AI Agent Security : le trio mortel décrypté

Début 2026, des chercheurs en cybersécurité ont découvert plus de 900 passerelles d’agents IA exposées sur Internet sans aucune authentification : clés API, jetons OAuth et historiques complets de conversations stockés en clair, accessibles à toute personne trouvant l’endpoint. Les organisations n’avaient pas été négligentes. Elles avaient suivi les workflows de déploiement standards. Le problème était structurel : il n’existait aucune couche de gouvernance sous l’agent.

Ces incidents ont servi de cas d’étude dans un article évalué par des pairs, publié le 29 avril 2026 dans Academia AI and Applications. L’article — Towards Trustworthy Agentic AI (Qi et al.) — a été rédigé par des chercheurs de The Chinese University of Hong Kong, de Fudan University et de la Shanghai Academy of AI for Science. Trente-six pages, aucune affiliation commerciale, évaluation par des pairs. Une analyse rigoureuse des raisons pour lesquelles les agents IA échouent en production et des moyens d’y remédier.

L’article cartographie les risques tout au long d’un cycle de vie de l’agent en cinq étapes — Percevoir, Planifier, Agir, Réfléchir et Apprendre — en documentant des modes d’échec précis avec des attaques réussies sur des systèmes déployés. Son cadre de remédiation n’est pas théorique. Il décrit les contrôles déjà exigés par les cadres réglementaires existants, mais que la plupart des déploiements IA en entreprise n’appliquent pas.

5 points clés à retenir

1. La plupart des agents IA d’entreprise sont structurellement exploitables par conception.

Des chercheurs de trois grandes institutions ont publié en 2026 une étude évaluée par des pairs démontrant que tout agent accédant simultanément à des données privées, traitant du contenu externe non fiable et communiquant avec l’externe est vulnérable à l’injection indirecte de prompts — une faille structurelle, et non une erreur de configuration. La combinaison qui rend les agents utiles est précisément celle qui les rend exploitables. Une gouvernance IA qui s’arrête aux prompts système ne peut pas contrer ce type d’attaque.

2. Les défenses au niveau du modèle ne stoppent pas les attaques au niveau des données.

Les prompts système et la formation à la sécurité IA agissent au-dessus de la couche de données et ne peuvent pas empêcher un agent d’exécuter des instructions injectées dans le contenu récupéré. La faille EchoLeak (CVE-2025-32711) dans Microsoft 365 Copilot l’a démontré à grande échelle : des e-mails spécialement conçus ont déclenché une fuite de données sans aucune interaction utilisateur. L’application des contrôles doit s’effectuer au niveau de l’accès aux données, indépendamment du modèle.

3. Le fossé de gouvernance est large et documenté.

Seules 43 % des organisations disposent aujourd’hui d’une passerelle centrale de données IA. Les 57 % restantes sont fragmentées, partielles ou fonctionnent sans gouvernance IA significative — 7 % n’ont aucun contrôle d’accès dédié à l’IA. Les organisations sans piste d’audit probante présentent un écart de maturité de 20 à 32 points sur chaque dimension de gouvernance IA selon les Prévisions Kiteworks 2026.

4. Les réglementations existantes s’appliquent déjà aux agents IA, sans exception.

HIPAA, CMMC, PCI DSS et SOX ne prévoient aucune exemption pour l’IA. Les mêmes obligations de contrôle d’accès, de chiffrement et de piste d’audit qui s’appliquent à l’accès humain aux données s’appliquent également à l’accès des agents IA — dès aujourd’hui, sans attendre de mises à jour réglementaires spécifiques à l’IA. La plupart des organisations ne peuvent pas actuellement prouver la conformité pour les interactions des agents.

5. Les incidents OpenClaw et Moltbook l’ont démontré à grande échelle.

Plus de 900 passerelles d’agents exposées, avec des identifiants en clair et sans authentification. Une fuite associée a exposé plus de 32 000 clés API d’agents enregistrés via une base de données mal configurée. Des plugins malveillants dans des marketplaces d’agents grand public ont été confirmés comme exfiltrant des identifiants vers l’externe. Il ne s’agit pas de scénarios hypothétiques — ce sont des échecs de production documentés en 2026, cités comme preuves dans l’étude évaluée par des pairs.

La triade fatale — Pourquoi la plupart des déploiements sont déjà compromis

Le concept le plus opérationnel de l’article est la « triade fatale » : tout agent IA qui (1) accède à des données privées, (2) traite du contenu externe non fiable et (3) peut communiquer avec l’externe est structurellement exploitable. Lorsque ces trois conditions sont réunies — ce qui est presque toujours le cas en production, car c’est précisément ce qui rend les agents utiles — un attaquant qui influence ce que l’agent récupère peut contrôler ses actions.

Cette catégorie d’attaque s’appelle l’injection indirecte de prompts. L’attaquant n’a qu’à placer des instructions malveillantes dans un contenu que l’agent va récupérer — une page web, un e-mail, un document, un enregistrement de base de données. L’agent traite le contenu, rencontre les instructions injectées et les exécute avec les autorisations dont il dispose déjà. Le cas réel cité par l’article est EchoLeak (CVE-2025-32711) dans Microsoft 365 Copilot : des e-mails spécialement conçus ont déclenché une fuite de données sans aucune action utilisateur, à l’échelle de l’entreprise, sans intervention humaine requise.

L’article explique clairement pourquoi les défenses au niveau du modèle ne suffisent pas à combler cette faille. Les grands modèles de langage ne distinguent pas de façon fiable les instructions légitimes des instructions injectées dans les données — le modèle voit les tokens dans leur contexte et ne peut pas vérifier leur provenance. L’application des contrôles doit s’effectuer au niveau des données, indépendamment du comportement du modèle, au moment où l’agent demande l’accès. Un régulateur qui demande une preuve de contrôle d’accès n’acceptera pas un prompt système comme réponse.

Comment l’attaque se déroule à chaque étape du cycle de vie de l’agent

L’analyse du cycle de vie dans l’article est sans ambiguïté : lors des incidents OpenClaw, aucune étape n’a échoué seule — toutes ont échoué en même temps. À l’étape Percevoir, des entrées non authentifiées et des injections de prompts sont passées sans validation. À l’étape Planifier, des instructions injectées ont modifié le plan de l’agent pour inclure des étapes d’exfiltration sans qu’aucun contrôle ne signale la déviation. À l’étape Agir, un accès sans restriction aux outils a permis l’exécution de commandes contrôlées par l’attaquant sans application du principe du moindre privilège.

À l’étape Réfléchir, aucune détection d’anomalie n’a signalé d’accès inhabituel aux identifiants ou de volumes de transmission anormaux. À l’étape Apprendre, des compétences malveillantes se sont propagées via le mécanisme d’installation sans vérification de provenance ni contrôle de régression. Les chercheurs qualifient cela d’échec « systémique » : chaque couche était dépourvue de contrôle spécifique au contexte des agents IA.

La dimension supply chain est particulièrement critique. Une étude empirique citée dans l’article a analysé 31 132 compétences d’agents et constaté que 26,1 % comportaient au moins une vulnérabilité de sécurité — exfiltration de données (13,3 %), élévation de privilèges (11,8 %) et injection de prompts, sur des compétences proposées dans des marketplaces d’agents grand public, installées par les développeurs car jugées utiles. La fuite Moltbook l’a illustré directement : des plugins malveillants ont été confirmés comme lisant des fichiers de configuration privés et transmettant des clés API à des serveurs externes.

Le fossé de conformité que les déploiements d’agents IA créent dès maintenant

Les enjeux de conformité ne relèvent pas du futur. HIPAA impose des contrôles d’accès sur les informations médicales protégées — aucune exemption pour l’IA. CMMC exige une autorisation documentée et validée pour tout accès à des CUI, quel que soit le type de système. PCI DSS restreint l’accès aux données de titulaires de carte, indépendamment du workflow. SOX ITGC impose un contrôle documenté sur l’accès aux systèmes de reporting financier. L’obligation de conformité applicable aux utilisateurs humains s’applique de façon identique à l’accès des agents IA — dès aujourd’hui.

Ce qu’un auditeur de conformité va demander, c’est une preuve : des journaux d’accès indiquant quel agent a accédé à quelles données, selon quelle règle, validé par quel responsable humain, à quelle date. La formation à la sécurité du modèle ne produit rien de tout cela. Selon les Prévisions Kiteworks 2026, 33 % des organisations ne peuvent actuellement fournir cette preuve pour aucune interaction sur les données, et encore moins pour celles spécifiques à l’IA. Les organisations sans piste d’audit présentent un écart de maturité de 20 à 32 points sur chaque dimension de gouvernance IA — un écart significatif. Cela traduit des niveaux de préparation radicalement différents. Le fossé est le plus large là où les enjeux sont les plus élevés : 90 % des organismes publics n’ont pas de passerelle centrale de données IA, 77 % des organismes de santé n’en ont pas, 60 % des acteurs des services financiers n’en ont pas.

Six contrôles jugés incontournables par la recherche

L’article identifie six contrôles qui, ensemble, constituent la couche de gouvernance empêchant les types d’attaques décrits. Chacun correspond directement à une exigence réglementaire existante.

Authentification de l’identité de l’agent. Chaque agent IA doit être authentifié avant d’accéder à toute donnée, avec une authentification liée à un responsable humain. C’est la même exigence d’authentification que celle imposée par HIPAA Section 164.312 et CMMC AC.1.001 aux utilisateurs humains.

Contrôle d’accès basé sur les attributs au niveau de l’opération. Chaque demande d’accès aux données doit être évaluée selon une règle multidimensionnelle — profil de l’agent, classification des données, opération demandée — avant de fournir la donnée. Les autorisations globales à la connexion sont insuffisantes.

Chiffrement validé FIPS. Les données en transit et au repos doivent être chiffrées avec des modules cryptographiques validés. Les incidents OpenClaw impliquaient un stockage d’identifiants en clair. Exigé par HIPAA Section 164.312(a)(2)(iv), CMMC SC.3.177 et PCI DSS Exigence 4.

Journalisation d’audit infalsifiable avec intégration SIEM. Chaque interaction d’agent doit être enregistrée dans un journal immuable retraçant l’identité de l’agent, le responsable humain, l’opération, les données accédées et le contexte de la règle — le tout transmis en temps réel aux opérations de sécurité.

Gestion des identifiants avec jetons éphémères. Les agents ne doivent jamais stocker de clés API ou de jetons OAuth en clair. Les secrets doivent être récupérés via des API de coffre-fort sécurisé, limités à chaque tâche, et renouvelés en continu.

Intégration Zéro trust. Tout contenu externe doit être considéré comme non fiable jusqu’à validation, avec une séparation stricte entre les prompts système de confiance et le contenu récupéré de l’externe. C’est le contrôle architectural qui empêche l’injection indirecte de prompts de réussir, même si le modèle ne distingue pas l’instruction légitime de l’instruction injectée.

Comment Kiteworks comble le fossé de gouvernance identifié par la recherche

Les six contrôles exigés par l’article sont précisément ceux que propose Kiteworks Compliant AI — au niveau des données, indépendamment du modèle ou du framework d’agent IA. Chaque requête est authentifiée via OAuth 2.0, autorisée selon des règles ABAC évaluées en temps réel, chiffrée avec des modules validés FIPS 140-3, et journalisée dans une piste d’audit infalsifiable alimentant directement les systèmes SIEM. Même si le modèle est compromis, mis à jour ou manipulé par injection de prompt, la couche de gouvernance des données continue d’appliquer la règle.

Le serveur Kiteworks Secure MCP permet à des assistants IA comme Claude et Microsoft Copilot d’interagir avec les données d’entreprise via le Model Context Protocol — chaque opération étant régie par les mêmes règles ABAC et la même piste d’audit que l’accès utilisateur humain. La passerelle de données IA applique la même gouvernance aux pipelines RAG programmatiques et aux workflows automatisés. Les deux appliquent les contrôles exigés par l’article. Le Réseau de données privé Kiteworks étend cette architecture à la messagerie électronique, au partage de fichiers, au MFT, au SFTP, aux formulaires web et aux API — un moteur de règles unique, un journal d’audit consolidé, des preuves de conformité générées automatiquement pour chaque interaction d’agent.

Ce que les organisations doivent faire avant le prochain déploiement d’agent

Première étape : auditez la triade fatale pour chaque agent déployé. Accède-t-il à des données privées ? Traite-t-il du contenu externe non fiable ? Peut-il communiquer avec l’externe ? Si les trois réponses sont oui, il est structurellement vulnérable. 57 % des organisations n’ont actuellement pas la visibilité centralisée pour répondre à ces questions selon les Prévisions Kiteworks 2026.

Deuxième étape : vérifiez que les contrôles d’accès s’appliquent au niveau de l’opération. Un agent autorisé à accéder à un dossier ne doit pas être automatiquement autorisé à en télécharger le contenu, envoyer des e-mails ou exécuter des commandes shell. 63 % des organisations ne peuvent pas limiter les usages des agents IA selon les Prévisions Kiteworks 2026.

Troisième étape : recensez les compétences et plugins des agents selon les schémas de vulnérabilité connus. 26,1 % des compétences d’agents analysées contenaient au moins une faille de sécurité. Évaluez les compétences installées, les autorisations demandées, les communications réseau initiées et si elles ont été signées cryptographiquement par un éditeur vérifiable.

Quatrième étape : confirmez que la journalisation d’audit couvre les interactions des agents IA et produit des traces infalsifiables. Si la journalisation ne permet pas d’identifier quel agent a accédé à quelles données, selon quelle règle, validé par quel responsable humain, à quelle date — elle ne satisfera pas à un audit de conformité. 33 % des organisations n’ont actuellement pas cette capacité pour aucune interaction sur les données.

Cinquième étape : mettez en place une gestion des identifiants spécifique aux agents IA. Les clés API et jetons OAuth utilisés par les agents ne doivent pas être stockés en clair, doivent être limités aux autorisations minimales nécessaires et renouvelés selon un calendrier défini avec révocation automatisée.

La fenêtre pour mettre en place une infrastructure de gouvernance avant qu’un événement réglementaire ou coercitif ne la rende obligatoire se referme rapidement. Les agents sont déjà en production. Les interactions ont déjà lieu. La question est de savoir si elles s’effectuent dans un cadre de gouvernance défendable.

Pour en savoir plus sur la protection des données sensibles face aux workflows IA, réservez votre démo personnalisée sans attendre.

Ressources complémentaires

• Article de blog
  Stratégies Zero‑Trust pour une protection abordable de la confidentialité IA
• Article de blog
  Pourquoi 77 % des organisations échouent en sécurité des données IA
• eBook
  Fossé de gouvernance IA : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025
• Article de blog
  Il n’existe pas de « –dangerously-skip-permissions » pour vos données
• Article de blog
  Les régulateurs ne se contentent plus de savoir si vous avez une politique IA. Ils veulent des preuves concrètes.