Les agents OpenClaw peuvent être poussés à l'auto-sabotage par culpabilisation

L'IA fiduciaire : les agents doivent prouver leur fiabilité, pas seulement leur capacité

Vijil, une entreprise spécialisée dans l'évaluation de la fiabilité des agents IA, propose un nouveau cadre baptisé "agent fiduciaire" pour repenser la manière dont les entreprises jugent leurs systèmes d'intelligence artificielle. Selon Vin Sharma, fondateur et PDG de Vijil, la plupart des organisations continuent de traiter la confiance envers un agent comme un exercice ponctuel réalisé avant sa mise en production, validé par des tests en environnement contrôlé et des évaluations de sécurité classiques. Or, dès qu'un agent commence à interagir avec le monde réel, cette confiance initiale s'effrite, car les modèles sous-jacents sont entraînés sur des données statiques déjà dépassées au moment du déploiement. Sharma pointe trois failles des benchmarks traditionnels: ils sont figés dans le temps alors que le monde évolue, ils modélisent la réalité de façon imparfaite, et surtout ils sont publics, ce qui permet aux modèles de mémoriser les réponses plutôt que de prouver une réelle capacité. Un agent peut ainsi obtenir un excellent score sur un test sans que cela garantisse une performance fiable en production. Cette distinction entre capacité et fiabilité change concrètement la façon dont les entreprises devraient évaluer leurs agents IA avant de leur déléguer des tâches sensibles. Vijil emprunte le concept de devoir fiduciaire aux professions réglementées, comme la finance ou la santé, où le prestataire doit faire primer les intérêts de son client sur les siens. Appliqué à un agent, cela se traduit par trois obligations testables indépendamment de toute conscience: le devoir de compétence, le devoir de vigilance et le devoir de loyauté envers l'entreprise qui le déploie. Concrètement, un agent est jugé digne de confiance si le bénéfice de lui déléguer une tâche dépasse le risque associé à un éventuel échec, une équation directement exploitable par les dirigeants pour arbitrer leurs déploiements d'IA. Ce risque se décompose en trois critères mesurables: la fiabilité, soit la capacité de l'agent à bien fonctionner dans des conditions variables, la sécurité, soit sa résistance face à des attaques malveillantes, et la sûreté, soit l'ampleur des dégâts en cas d'échec. Vijil compare le score qui en résulte à une note de crédit, mais construite à partir de données comportementales plutôt que financières. Cette approche répond à un problème plus large de l'industrie de l'IA agentique, où l'accent a longtemps porté presque exclusivement sur les capacités techniques des modèles, en négligeant la question de savoir si un agent agit réellement dans l'intérêt de l'organisation qui l'emploie, un enjeu appelé à prendre de l'ampleur à mesure que les agents gagnent en autonomie dans les entreprises.

OpenAI étend l'évaluation des risques pré-déploiement au codage à base d'agents via des appels d'outils simulés

OpenAI a publié une nouvelle méthode de sécurité pré-déploiement baptisée Deployment Simulation, décrite dans un document technique mis en ligne sur son site. Le principe est simple : avant qu'un modèle soit mis en production, on simule son déploiement à l'avance. Concrètement, OpenAI rejoue des conversations réelles passées en remplaçant les réponses de l'ancien modèle par celles du nouveau candidat, puis analyse les résultats pour détecter d'éventuels comportements indésirables. La méthode est conçue pour préserver la vie privée des utilisateurs et produit une estimation du taux de comportements problématiques par message, vérifiable après la mise en ligne sur le trafic réel. La technique présente toutefois une limite inhérente : elle ne peut pas détecter des comportements qui se produisent moins d'une fois tous les 200 000 messages, ce qui la cantonne aux risques non marginaux. L'intérêt principal de cette approche réside dans ce qu'elle corrige par rapport aux évaluations traditionnelles. Celles-ci reposent sur des jeux de données synthétiques ou construits manuellement, sélectionnés pour être difficiles ou adversariaux, ce qui introduit trois biais connus : une sélection partiale des prompts, une couverture limitée, et une «conscience de l'évaluation» car le modèle peut réagir différemment à des contextes clairement artificiels. La Deployment Simulation, en s'appuyant sur une distribution représentative du trafic réel, réduit ces trois problèmes simultanément. La qualité de l'estimation croît avec la puissance de calcul disponible, et non avec l'effort humain nécessaire pour construire des benchmarks. OpenAI précise que la méthode a déjà informé des décisions de déploiement concrètes et mis en évidence des angles morts dans les évaluations classiques. Cette publication s'inscrit dans un effort plus large de l'industrie pour combler l'écart entre les tests de sécurité en laboratoire et les comportements réels des modèles en production. Les évaluations traditionnelles restent indispensables pour les risques rares et à haute sévérité, que la Deployment Simulation ne peut pas couvrir en dessous d'un certain seuil de prévalence. OpenAI présente les deux approches comme complémentaires plutôt que concurrentes. Alors que les grands laboratoires intensifient leurs travaux sur les systèmes agentiques, capables d'exécuter des tâches autonomes et d'appeler des outils externes, la question de la sécurité pré-déploiement devient plus critique. La méthode offre un cadre scalable pour anticiper les dérives avant qu'elles n'atteignent des millions d'utilisateurs, ce qui représente un pas méthodologique concret dans un domaine où les standards restent encore largement à construire.

Amazon utilise des agents IA pour la détection de vulnérabilités à grande échelle

En 2025, la base de données nationale des vulnérabilités américaine (NVD) a enregistré plus de 48 000 nouvelles failles de sécurité référencées (CVE), un volume rendu possible en grande partie par la prolifération des outils automatisés de détection. Face à cette explosion, Amazon Web Services a développé RuleForge, un système d'intelligence artificielle agentique conçu pour générer automatiquement des règles de détection à partir d'exemples de code d'exploitation de vulnérabilités. Déployé en production chez AWS, RuleForge affiche une productivité supérieure de 336 % à la création manuelle, tout en conservant le niveau de précision exigé pour des systèmes de sécurité industriels. Les règles produites sont au format JSON et alimentent directement MadPot, le système mondial de "honeypot" d'Amazon qui capture le comportement des attaquants, ainsi que Sonaris, le moteur interne de détection d'exploits suspects. Avant RuleForge, transformer une CVE en règle de détection opérationnelle était un processus entièrement manuel : un analyste téléchargeait le code de preuve de concept, étudiait le mécanisme d'attaque, rédigeait la logique de détection, la validait par itérations successives contre les journaux de trafic, puis soumettait le tout à une revue par un second ingénieur avant déploiement. Ce cycle, rigoureux mais lent, obligeait les équipes à prioriser strictement les vulnérabilités traitées, laissant potentiellement des failles critiques sans couverture. RuleForge comprime ce délai de façon drastique : le système ingère automatiquement le code d'exploitation public, attribue un score de priorité via une analyse de contenu croisée avec des sources de threat intelligence, puis génère en parallèle plusieurs règles candidates via un agent tournant sur AWS Fargate avec Amazon Bedrock. Chaque candidate est évaluée non pas par le modèle qui l'a produite, mais par un agent "juge" distinct, évitant ainsi l'auto-validation biaisée. Les humains restent dans la boucle pour l'approbation finale avant mise en production. Cette architecture reflète une tendance profonde dans la sécurité offensive et défensive : l'automatisation par IA ne remplace pas les experts, elle leur permet de travailler à une échelle autrement inaccessible. AWS anticipe une croissance continue du nombre de CVE à haute sévérité publiées, portée par les mêmes outils d'IA qui accélèrent la découverte de failles côté attaquants. RuleForge représente la réponse symétrique côté défense, en industrialisant la réactivité. L'approche modulaire, avec des agents spécialisés pour la génération, l'évaluation et le raffinement, plutôt qu'un seul modèle monolithique, s'inscrit dans la lignée des architectures multi-agents qui émergent comme standard pour les tâches complexes nécessitant fiabilité et auditabilité. D'autres grands acteurs du cloud font face aux mêmes défis, et la publication par Amazon des détails de RuleForge suggère une volonté de positionner cette approche comme référence sectorielle.

Les agents IA de GitHub peuvent faire fuiter un dépôt privé via une injection de prompt

Des chercheurs en sécurité de l'entreprise Noma ont démontré une faille baptisée GitLost dans les GitHub Agentic Workflows, la fonctionnalité d'agents IA de GitHub lancée en préversion publique le 11 juin dernier. En se faisant passer pour un vice-président des ventes, les chercheurs ont ouvert un simple ticket de rapport d'erreur sur un dépôt public, glissant au milieu du message une question anodine en apparence sur le contenu du fichier README de deux dépôts privés de la même organisation, nommés « poc » et « testlocal ». Dès que le ticket a été attribué à l'agent IA, celui-ci a récupéré le contenu de ces fichiers privés et l'a recopié directement dans sa réponse publique au ticket, rendant ainsi accessible à tous une information censée rester confidentielle. Selon Noma, c'est l'ajout d'un simple mot de transition, « Additionally », qui a suffi à faire basculer l'agent d'une tâche légitime vers l'exécution de la requête malveillante cachée dans le message. Cette découverte fragilise un peu plus la confiance des développeurs envers GitHub, qui avait pourtant présenté ses agents comme fortement sécurisés. Lancée en février dernier et utilisable avec Copilot CLI, Claude Code ou OpenAI Codex au choix, la fonctionnalité permet d'automatiser la gestion de documentation, de tickets de bugs ou de tests via les GitHub Actions. L'entreprise assurait disposer de plusieurs niveaux de protection : permissions en lecture seule par défaut, exécution en conteneur sandbox derrière un « Agent Workflow Firewall », filtre d'intégrité, validation des résultats et détection automatique des menaces sur toute modification proposée. La démonstration de Noma montre que ces garde-fous peuvent être contournés par une injection de prompt relativement simple, sans exploiter de faille technique complexe, ce qui pose un problème direct pour toute organisation ayant activé ces agents sur des dépôts mêlant contenus publics et privés. L'épisode illustre ce que l'ingénieur Simon Willison appelle le « trio mortel » des agents IA : l'accès à des données confidentielles, le traitement de contenus non fiables provenant de tiers, et la capacité à faire sortir de l'information vers l'extérieur. Dès lors que ces trois conditions sont réunies, comme c'est le cas avec un agent capable de lire des dépôts privés tout en traitant des tickets ouverts par n'importe quel utilisateur externe, l'injection de prompt devient une voie d'attaque quasiment inévitable. GitHub n'a pas encore communiqué publiquement de correctif spécifique face à cette démonstration, alors que l'adoption des agents IA dans la gestion de code se généralise chez de nombreuses entreprises.

💬 Le détail qui tue : un simple mot, « Additionally », glissé dans un ticket public, a suffi à faire cracher à l'agent le contenu de deux dépôts privés. GitHub vendait ses gardes-fous comme du béton armé (sandbox, firewall, permissions en lecture seule) et ça n'a pas tenu deux minutes face à une injection de prompt basique. Dès qu'un agent IA cumule accès aux données privées, lecture de contenus venant d'inconnus et capacité à publier une réponse, la fuite n'est plus une hypothèse, c'est une question de temps.