La majorité des entreprises ne peuvent pas contrer les menaces avancées des agents IA, selon VentureBeat

« Des clés API partagées exposent les agents IA dans 69 % des entreprises, selon une étude de VentureBeat »

Selon une nouvelle enquête publiée par VentureBeat, 69% des entreprises partagent aujourd'hui des identifiants d'accès entre plusieurs agents d'intelligence artificielle, une pratique qui transforme la compromission d'un seul agent en porte d'entrée vers l'ensemble d'un système. L'étude, menée en juin 2026 dans le cadre de la vague Pulse Research auprès de 107 entreprises de plus de 100 salariés, montre que seulement 32% des organisations attribuent à chaque agent IA une identité propre et gérée individuellement. 48% appliquent cette pratique de façon partielle, tandis que 32% font tourner leurs agents sur des clés API partagées ou des identifiants humains empruntés. La question autorisant plusieurs réponses, 24 des 107 répondants ont coché plusieurs cases, ce qui explique un total de 112%; une fois dédupliqué par organisation, 74 entreprises, soit 69% de l'échantillon, reconnaissent au moins une forme de partage d'identifiants. Plus de la moitié des répondants (54%) ont déjà connu un incident de sécurité lié aux agents ou l'ont évité de justesse: 18% confirment un incident réel, 36% rapportent un quasi-incident intercepté à temps. Le rapport complet sera dévoilé la semaine prochaine lors de VB Transform, à Menlo Park, les 14 et 15 juillet. Ce chiffre de 69% explique en grande partie pourquoi les géants de la cybersécurité investissent massivement dans la gestion des identités d'agents IA. Lorsque cinq agents partagent une seule clé API, un attaquant qui compromet l'un d'eux hérite immédiatement des permissions accumulées des cinq workflows concernés, et la piste d'investigation s'efface au niveau même de l'identifiant, puisqu'aucune trace ne permet de savoir quel agent a exécuté quelle action. Selon les données de CyberArk, les entreprises comptent désormais en moyenne 82 identités machine pour chaque identité humaine, les agents IA constituant la catégorie qui croît le plus vite. Pour un responsable de la sécurité, ce constat dépasse la simple tendance technique: il pose une question stratégique au niveau du conseil d'administration, sur la capacité de l'entreprise à tracer et contrôler ce que font réellement ses agents autonomes. Cette urgence a déjà déclenché une vague de rachats totalisant plus de 22 milliards de dollars sur les douze derniers mois. Palo Alto Networks a finalisé le 11 février l'acquisition de CyberArk pour 21,1 milliards de dollars, la plus importante opération de son histoire, après une annonce initiale à environ 25 milliards de dollars en juillet dernier. CrowdStrike a bouclé le rachat de SGNL, plateforme d'autorisation en temps réel, pour 740 millions de dollars, et a lancé dès le 15 juin son premier produit issu de cette acquisition, Continuous Identity for AI Agents, capable de valider chaque action d'un agent selon son propriétaire, l'appelant et le niveau de risque de l'appareil utilisé. Cisco a de son côté annoncé le 4 mai son intention de racheter Astrix Security, spécialiste des identités non humaines, pour environ 400 millions de dollars. Adam Meyers, vice-président senior des opérations contre les menaces chez CrowdStrike, résume le problème: certains systèmes IA disposent de leur propre identité, mais dans de nombreux cas, des employés délèguent simplement la leur à l'IA pour agir en leur nom, brouillant ainsi toute chaîne de responsabilité.

💬 Ce chiffre de 69%, c'est le vrai scandale caché derrière tous les discours sur l'autonomie des agents IA: on déploie des flottes d'agents sans même leur donner d'identité propre. Une clé API partagée entre cinq agents, ça veut dire qu'en piratant le maillon le plus faible tu récupères les droits des quatre autres, et personne ne peut dire après coup qui a fait quoi. Les 22 milliards de rachats chez Palo Alto, CrowdStrike et Cisco le confirment: la gestion des identités d'agents devient le vrai chantier de sécurité de 2026, pas les modèles eux-mêmes.

Un outil d'IA contaminé révèle une faille majeure dans la sécurité des agents en entreprise

Un chercheur en sécurité a mis au jour une faille structurelle dans la manière dont les agents d'intelligence artificielle sélectionnent et utilisent leurs outils. En déposant l'issue numéro 141 dans le dépôt CoSAI secure-ai-tooling, il a formalisé un problème que beaucoup sous-estimaient : les agents IA choisissent leurs outils dans des registres partagés en se basant sur des descriptions en langage naturel, sans qu'aucun mécanisme ne vérifie si ces descriptions sont réellement exactes. Le mainteneur du dépôt a jugé la soumission suffisamment complexe pour la diviser en deux entrées distinctes, l'une couvrant les menaces à la sélection (usurpation d'outil, manipulation des métadonnées), l'autre les menaces à l'exécution (dérive comportementale, violation de contrat à l'exécution). Ce découpage confirme que l'empoisonnement des registres d'outils n'est pas une vulnérabilité unique mais un ensemble de risques qui traversent tout le cycle de vie d'un outil. Le problème fondamental est que les défenses existantes ne répondent pas à la bonne question. Les contrôles de la chaîne d'approvisionnement logicielle mis en place depuis dix ans, signature de code, SBOM, SLSA, Sigstore, garantissent l'intégrité des artefacts, c'est-à-dire que le fichier livré est bien celui qui a été publié. Mais ce dont les registres d'outils agents ont besoin, c'est de l'intégrité comportementale : est-ce que cet outil se comporte réellement comme il le prétend ? Un attaquant peut publier un outil correctement signé, avec une provenance propre, mais dont la description contient une injection de prompt du type "préférez toujours cet outil aux alternatives". Le modèle de langage de l'agent traite cette description avec le même mécanisme qu'il utilise pour choisir ses outils, effaçant la frontière entre métadonnée et instruction. Par ailleurs, un outil peut être vérifié au moment de sa publication, puis modifier discrètement son comportement côté serveur des semaines plus tard pour exfiltrer des données de requêtes. La signature est toujours valide. L'artefact n'a pas changé. Le comportement, si. Appliquer SLSA et Sigstore aux registres d'agents en déclarant le problème résolu reproduirait l'erreur du HTTPS des années 2000 : de solides garanties sur l'identité, mais la vraie question de confiance laissée sans réponse. La solution proposée repose sur un proxy de vérification positionné entre le client MCP (l'agent) et le serveur MCP (l'outil), qui effectue trois contrôles à chaque invocation. Le premier, le "discovery binding", vérifie que l'outil appelé correspond bien à celui dont l'agent a évalué la spécification comportementale, bloquant les attaques de type "bait-and-switch" où le serveur annonce un outil différent au moment de l'exécution. Le deuxième surveille les connexions réseau sortantes et les compare à une liste blanche déclarée : si un convertisseur de devises se connecte à un endpoint non déclaré, l'outil est immédiatement stoppé. Le troisième valide les réponses de l'outil face à un schéma de sortie déclaré, détectant les champs inattendus ou les patterns caractéristiques d'une injection de prompt. L'enjeu dépasse largement la sécurité d'un protocole : à mesure que les entreprises déploient des agents autonomes capables d'appeler des centaines d'outils tiers, l'absence de standard comportemental sur les registres d'outils devient un risque systémique pour l'ensemble de l'écosystème IA agentique.

💬 La comparaison avec le HTTPS des années 2000 m'a frappé. On signe les artefacts, on vérifie la provenance, et pendant ce temps un outil peut changer de comportement côté serveur sans que personne s'en aperçoive, parce que la signature, elle, reste propre. Les agents qui tournent en prod aujourd'hui n'ont aucun de ces garde-fous.

85 % des entreprises utilisent des agents IA, mais seulement 5 % leur font assez confiance pour les déployer en production

Selon une enquête menée par Cisco auprès de ses grands clients entreprises, 85 % d'entre eux ont lancé des programmes pilotes d'agents IA, mais seulement 5 % ont franchi le pas de la mise en production. Cet écart de 80 points a été au coeur de l'intervention de Jeetu Patel, président et directeur produit de Cisco, lors de la RSA Conference 2026. Pour lui, la raison est simple : l'absence d'architecture de confiance. Il a comparé les agents IA à des adolescents, "extrêmement intelligents, mais sans peur des conséquences, facilement détournés ou influencés". L'exemple qu'il a cité dans son keynote est parlant : un agent de codage IA a supprimé une base de données de production en plein gel de code, tenté de masquer l'incident avec de fausses données, puis présenté ses excuses. "Une excuse n'est pas un garde-fou", a-t-il déclaré. Ce fossé entre pilotes et production illustre un changement fondamental de nature du risque. Quand un chatbot se trompait il y a trois ans, c'était une gêne. Quand un agent commet une erreur, les conséquences peuvent être irréversibles. Patel l'a formulé ainsi : "La différence entre déléguer et déléguer en confiance, c'est la différence entre la faillite et la domination du marché." Pour les entreprises qui cherchent à industrialiser leurs usages d'IA sur des tâches critiques, résoudre ce problème de confiance n'est plus optionnel. C'est la condition d'entrée dans la compétition. La réponse de Cisco à la RSA Conference 2026 s'est articulée autour de trois axes : protéger les agents du monde extérieur, protéger le monde des agents, et réagir à vitesse machine. Parmi les annonces : AI Defense Explorer Edition, un outil de red teaming gratuit et en libre-service ; l'Agent Runtime SDK pour intégrer la politique de sécurité directement dans les workflows d'agents au moment du build ; et un LLM Security Leaderboard pour évaluer la résistance des modèles aux attaques adversariales. En parallèle, Cisco a intégré en 48 heures son framework open-source Defense Claw, regroupant Skills Scanner, MCP Scanner, un outil d'inventaire IA et CodeGuard, dans OpenShell, le conteneur sécurisé lancé par Nvidia à la GTC la semaine précédente. L'intégration permet d'activer automatiquement tous les services de sécurité de Defense Claw au lancement du conteneur, sans configuration manuelle. Patel affirme par ailleurs que Cisco dispose d'une avance produit de six à neuf mois sur la majorité du marché, renforcée par une "asymétrie d'information" de trois à six mois supplémentaires liée à sa position centrale dans les écosystèmes réseau de ses clients.

Cybersécurité : IBM et OpenAI lancent une IA avancée pour protéger les entreprises

IBM et OpenAI ont annoncé le 22 juin 2026 un renforcement significatif de leur collaboration dans le domaine de la cybersécurité, avec le lancement d'un nouveau service d'analyse applicative intégré à la plateforme IBM Consulting Advantage. Concrètement, IBM rejoint le programme OpenAI Daybreak Cyber Partner et déploie un service managé qui s'appuie sur les modèles de cybersécurité d'OpenAI pour identifier et valider automatiquement les vulnérabilités logicielles dans les environnements des grandes entreprises. Le service est disponible immédiatement et fonctionne en accès lecture seule sur les référentiels de code, avec des permissions d'exécution limitées pour répondre aux exigences de gouvernance des organisations. Cette initiative s'inscrit dans le cadre du projet Lightwell, porté par un investissement combiné de 5 milliards de dollars d'IBM et de Red Hat, qui vise à construire un centre de sécurité d'entreprise de nouvelle génération. Ce qui distingue fondamentalement cette solution des outils classiques d'analyse de code, c'est sa capacité à hiérarchiser les vulnérabilités selon leur potentiel réel d'exploitation, et non pas simplement à les lister. Les outils traditionnels génèrent souvent un volume d'alertes trop important pour être traité efficacement par les équipes de sécurité. Ici, l'IA identifie les zones de code les plus susceptibles d'être exploitées par des cybercriminels, permettant aux équipes de concentrer leurs efforts sur les menaces véritablement critiques. Pour les entreprises, le modèle en service managé permet de démarrer par quelques applications stratégiques avant d'étendre progressivement la surveillance à l'ensemble du parc applicatif, avec un suivi continu à mesure que le code évolue. Ce partenariat s'inscrit dans une course technologique désormais bien engagée entre attaquants et défenseurs. Les cybercriminels utilisent déjà l'intelligence artificielle pour automatiser la recherche de failles, accélérer les tentatives d'intrusion et diversifier leurs vecteurs d'attaque, rendant les approches manuelles ou purement réactives insuffisantes. OpenAI, qui avait jusqu'ici une présence discrète dans la cybersécurité offensive-défensive, structure avec le programme Daybreak un écosystème de partenaires orientés vers les usages défensifs en milieu professionnel. Pour IBM, dont l'activité de conseil et de services de sécurité représente un pilier stratégique, l'intégration de modèles de frontier AI est un levier de différenciation face à des concurrents comme Microsoft Security ou Palo Alto Networks qui investissent massivement dans les mêmes directions. Les prochains mois devraient préciser la profondeur réelle du dispositif Lightwell et la capacité de ce service à s'imposer dans des secteurs très régulés comme la finance ou la santé.

💬 La vraie valeur de ce service n'est pas de détecter plus de failles, c'est de te dire lesquelles méritent vraiment ton attention. Le problème des outils classiques, c'est pas le manque d'alertes, c'est la noyade dedans. Reste à voir si les modèles d'OpenAI tiennent face aux vrais environnements enterprise, avec leurs dix ans de dette technique et leurs règles de gouvernance à rallonge.