Une analyse publiée par The Hacker News soutient que l'essentiel de la sécurité de l'IA en entreprise vise la mauvaise cible. L'article, contribué par un partenaire et contenant du matériel promotionnel, affirme que les contrôles conçus pour l'IA qu'une entreprise a délibérément adoptée ne voient pas les agents qui arrivent à l'intérieur des logiciels qu'elle utilise déjà. Il s'agit d'un article d'opinion. Il ne décrit ni une intrusion, ni une vulnérabilité, ni une mesure de répression.
Trois façons pour un agent d'entrer dans l'entreprise
L'auteur classe les agents selon leur mode d'arrivée :
- Hérité : intégré à une plateforme existante grâce à une mise à jour courante du produit.
- Configuré : construit à partir des consignes et de la logique propres à l'entreprise, mais fonctionnant sur l'environnement d'exécution, le modèle et les connecteurs d'un éditeur.
- Construit : assemblé à partir de frameworks ouverts, sur une infrastructure que possède l'entreprise.
Selon l'auteur, les deux premières catégories représentent « l'écrasante majorité » des adoptions et progressent « de façon exponentielle ». Les agents construits forment le groupe le plus restreint et celui qui croît le plus lentement. L'article n'avance aucune mesure à l'appui de ces caractérisations.
La conséquence, selon l'auteur, est que personne ne décide d'adopter un agent hérité. Il apparaît avec une mise à jour, si bien que l'examen qui précède normalement un nouveau déploiement d'IA n'a jamais lieu.
Un chiffre tiré d'un rapport non nommé
L'article cite le « 2026 State of Agent Security Report », sans l'attribuer à un éditeur ni décrire sa méthode ou son échantillon. D'après ce rapport, environ 1 280 produits tiers présents dans les environnements étudiés intègrent de l'IA. Environ 282 d'entre eux passent par une authentification unique.
L'auteur interprète cet écart comme laissant « les mille autres » invisibles par défaut pour l'infrastructure d'identité. Il s'agit de décomptes de produits, et non d'agents ou de personnes. Les autres exemples d'échelle de l'article, cinquante, cinq cents et cinq mille agents, sont des illustrations et non des données.
L'exemple de Slack Code
L'étude de cas principale de l'auteur est Slack Code, que l'article présente comme lancé par Salesforce en août 2026. Un utilisateur mentionne l'agent de programmation dans une conversation. Selon l'article, celui-ci lit le contexte partagé, écrit du code et ouvre des pull requests, avec un accès à GitHub et à l'infrastructure de production.
L'annonce de Salesforce, citée dans l'article, affirme que les agents « héritent du modèle de sécurité, des autorisations et des contrôles d'administration intégrés de Slack dès le premier jour, sans effort supplémentaire de la part du service informatique ». L'article oppose cette promesse à la portée plus large de l'agent, au-delà de Slack lui-même.
Où l'auteur situe le risque
L'article soutient que le risque se situe surtout dans l'échafaudage de l'agent et dans son écosystème, et non dans le modèle sous-jacent. Il propose quatre axes d'examen :
- Identité : quel agent agit, et pour le compte de qui.
- Autorisations : ce qu'il est habilité à faire.
- Connectivité : le rayon d'impact, y compris ce qu'il peut atteindre indirectement via d'autres systèmes.
- Activité : une évaluation fondée sur le comportement observé, et non sur l'intention déclarée.
Opet et l'AI Act européen
L'auteur invoque Patrick Opet, RSSI mondial de JPMorgan Chase. En 2025, selon l'article, Opet a décrit la chaîne d'approvisionnement tierce comme un risque systémique. L'article ajoute que des incidents ont été assez graves pour que la banque isole des fournisseurs compromis, un point exposé dans une lettre ouverte. L'article ne donne aucun détail sur ces incidents.
L'auteur attribue également à Opet la position selon laquelle un agent devrait recevoir une identité mais aucune autorisation par défaut. Avant qu'il ne touche à quoi que ce soit en dehors de son périmètre, le service informatique devrait confirmer pour le compte de qui il agit.
Sur le plan réglementaire, l'auteur affirme que l'AI Act européen, dont les obligations s'appliquent par étapes jusqu'en 2026, suppose que les entreprises peuvent inventorier leurs systèmes d'IA, désigner leurs responsables et démontrer la supervision exercée. Cela est difficile, soutient l'article, lorsque les agents arrivent sans être annoncés à l'intérieur des produits des fournisseurs.
L'angle des fournisseurs
L'article cite Reco, et sa plateforme Reco Graph, comme un « exemple de premier plan » d'outil qui relie identités humaines et non humaines, applications, autorisations et actions des agents dans une vue en temps réel. L'article provient d'un partenaire : cet aval relève donc du plaidoyer de l'auteur de la contribution. La découverte d'agents par Reco est mentionnée à reco.ai/platform.
Pour les équipes de sécurité, la conclusion pratique est plus restreinte que le discours commercial. L'argument est qu'un inventaire des agents devrait partir des applications SaaS déjà utilisées, et non d'une liste de projets d'IA approuvés.
