Chaque trimestre, le projetOWASP Security publie une synthèse des Sécurité IA les plus marquants de la période, en les mettant en correspondance avec le OWASP 10 OWASP pour LLM et le nouveau Top 10 pour les applications agentiques. L'édition du premier trimestre 2026 mérite toute l'attention des responsables de la sécurité — non pas pour une faille en particulier, mais pour la tendance qui se dégage de l'ensemble de ces incidents.
Le résumé OWASP le dit clairement : le domaine est passé du risk théorique risk l’ exploitation concrète, et l’action ne se limite plus au modèle lui-même. Les attaquants et les défaillances ciblent désormais les identités des agents, les couches d’orchestration et les chaînes d’approvisionnement — et non plus simplement les résultats des modèles. Le mérite de la recherche sous-jacente revient à OWASP aux auteurs qu’il cite ; ce qui suit est mon analyse des quatre incidents les plus importants pour les entreprises soumises à une réglementation, ainsi que ce que chacun d’entre eux exige de vos contrôles.
« Pour garantir la sécurité de l'IA, il faut désormais passer de mesures de protection au niveau des modèles à des contrôles de sécurité globaux portant sur les systèmes, les identités et les opérations. » — Projet OWASP Security, bilan du 1er trimestre 2026
Cette phrase pourrait résumer la raison d'être de tout ce que nous développons chez OneCompliant. Ci-dessous, chaque incident est suivi de OneCompliant — c'est-à-dire le dispositif de contrôle qui aurait permis de le détecter ou de le contenir.
1. GrafanaGhost — quand votre tableau de bord devient une voie d'exfiltration
Selon le OWASP (qui cite une étude de Noma Security), les attaquants pouvaient dissimuler des instructions dans du contenu externe ingéré par l'assistant IA de Grafana. Ce contexte corrompu a poussé l’assistant à afficher une image externe — et cet appel de rendu a permis de faire sortir clandestinement des données d’entreprise vers un serveur contrôlé par l’attaquant sous la forme d’un paramètre d’URL. Grafana a corrigé le chemin de rendu des images Markdown et a précisé que l’exploitation de cette faille nécessitait une interaction significative de la part de l’utilisateur. Mais c’est la nature même de l’attaque qui importe : une couche d’observabilité de confiance, contenant des données de télémétrie, d’infrastructure, de clients et financières, s’est transformée en source de fuite.
Considérez tout ce qu’un AI ingère — journaux, liens, tableaux de bord, tickets — comme des données d’entrée non fiables, et réglementez ce qu’il est autorisé à transmettre. Il s’agit là d’une injection indirecte de prompt ; modélisez cette menace à l’instar du XSS ou du SSRF. Un assistant disposant d’un large accès aux données de télémétrie ne devrait jamais bénéficier en parallèle d’un canal de sortie sans restriction. Inspectez le contexte entrant dans le modèle ; contrôlez ce qui est autorisé à en sortir.
2. Vertex AI Double Agent » — l'identité est le nouveau périmètre
Selon ce tour d'horizon (qui cite l'unité 42 de Palo Alto), un agent déployé dans le Vertex AI Engine de Google Cloud a hérité de bien plus de droits que nécessaire via un compte de service géré par Google. Les chercheurs ont exploité cette identité aux droits excessifs pour extraire des identifiants, se faire passer pour l’agent de service, accéder aux ressources des projets clients, et même accéder à des images et au code source internes soumis à des restrictions. Google a par la suite révisé ses recommandations. La leçon à en tirer n’est pas que « Vertex n’est pas sûr », mais plutôt que les paramètres par défaut de la plateforme gérée ont accordé à un agent un accès plus étendu que ce qui était prévu.
L'identité des agents mérite d'être soumise au même niveau de contrôle que les accès administrateurs privilégiés. Il convient d'appliquer par défaut le principe du « moins d'agents possible », de définir un périmètre par déploiement, d'utiliser des identifiants à durée de vie limitée et de tenir à jour un inventaire en temps réel de toutes les identités de service liées à l'exécution des agents. Ne vous fiez pas aux paramètres par défaut de la plateforme : vérifiez explicitement si un agent est capable d'accéder à d'autres projets, buckets, registres ou infrastructures de modèles.
3. La fuite d'un agent interne chez Meta — l'ampleur des répercussions d'une réponse imprudente
Selon ce tour d’horizon (qui cite The Guardian), un ingénieur de Meta a demandé de l’aide sur un forum interne, un agent AI a proposé une solution, et l’ingénieur l’a mise en œuvre — exposant ainsi brièvement un volume important de données sensibles relatives aux utilisateurs et à l’entreprise aux ingénieurs pendant environ deux heures. Il n’y a pas eu d’attaquant externe et Meta a déclaré qu’ aucune donnée utilisateur n’avait été mal gérée, mais cela a tout de même déclenché une importante réaction interne en matière de sécurité. C’est une illustration parfaite de la manière dont une seule recommandation non sécurisée d’un agent peut se transformer en incident de contrôle d’accès à l’échelle de l’entreprise.
Il doit exister une couche de contrôle entre les conseils fournis par l'IA et leur mise en œuvre. Toute recommandation susceptible de modifier les autorisations, la visibilité des données ou policy faire l'objet d'une validation déterministe et d'un examen humain avant d'être appliquée, en particulier au sein des workflows d'ingénierie et de sécurité. Considérez les résultats fournis par l'agent comme non fiables jusqu'à ce qu'ils aient été vérifiés.
4. Mercor / LiteLLM — votre chaîne AI est plus vaste que vos modèles
Selon ce tour d’horizon (qui cite WIRED), Meta a suspendu sa collaboration avec le fournisseur AI Mercor à la suite d’une faille liée à des versions malveillantes de l’outil open source LiteLLM. Mercor assurant la génération de données d’entraînement propriétaires pour de grands laboratoires, cet incident a fait craindre que des méthodes de traitement des données d’entraînement sensibles et les activités des sous-traitants aient été exposées — ce qui a conduit à une réévaluation au sein de plusieurs laboratoires. La faille provenait d’une dépendance logicielle au sein de la pile AI, et non du modèle lui-même.
Votre chaîne AI comprend les bibliothèques d'orchestration, les intégrations MCP et les fournisseurs qui génèrent vos données. Identifiez et vérifiez les dépendances, exigez de AI des preuves de type SBOM et une maturité en matière de réponse aux incidents, et considérez les fournisseurs de données comme des partenaires essentiels au sein de votre programme de gouvernance — et non comme de simples notes de bas de page dans vos procédures d'approvisionnement.
Le fil qui les relie
OWASP une deuxième observation qui devrait vous amener à repenser votre approche des risk liés à l'IA : la plupart de ces incidents ne disposent pas de CVE. Il ne s'agit pas de bogues de code isolés, mais bien de mauvaises configurations, d'une autonomie excessive, de limites de confiance insuffisantes et de manipulations des flux de données. Seule une faille logicielle embarquée classique, comme la faille d’exécution de code à distance de Flowise (CVE-2025-59528), qui fait actuellement l’objet d’exploits actifs, s’inscrit parfaitement dans le cadre traditionnel de la gestion des vulnérabilités.
C'est là que réside la lacune. Si votre risk liés à l'IA repose uniquement sur la recherche de vulnérabilités CVE, il passe structurellement à côté de la plupart des défaillances réelles de l'IA. Il s'agit là de risques systémiques et architecturaux, qui nécessitent des contrôles fonctionnant au moment de l'exécution — couvrant l'identité, l'autonomie et les flux de données — et qui produisent des preuves.
« L'action s'est déplacée des résultats des modèles vers les identités, l'orchestration et les chaînes d'approvisionnement. La gouvernance doit suivre cette évolution : passer des documents aux contrôles opérationnels. »
C'est exactement la couche OneCompliant : OASF les domaines de contrôle, OASAT votre conformité par rapport à ceux-ci, et Aegis les Aegis au moment de l'utilisation — en inspectant les invites et le contexte, en régissant les données autorisées à sortir du système, en délimitant les actions autorisées aux agents, et en enregistrant chaque décision à titre de preuve. Des rapports comme OWASP sont le reflet de la réalité sur le terrain qui nous montre, incident après incident, pourquoi cette couche n’est plus facultative.
Lisez l'intégralité de ce tour d'horizon — c'est une ressource trimestrielle véritablement utile, et OWASP y contribuer : Tour d'horizon des faillesOWASP , 1er trimestre 2026 →
Ces incidents correspondent à des mesures de contrôle. Les avez-vous mises en place ?
OASAT votre AI par rapport à ces modes de défaillance précis — identité, capacité d'action, chaîne d'approvisionnement et flux de données — et Aegis les contrôles lors de l'exécution. Identifiez vos failles avant qu'elles ne vous valuent une mention dans le classement.