Les agents IA gèrent dossiers médicaux et inspections d'usines : l'IAM en entreprise n'était pas conçu pour eux

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.

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

En mars dernier, un agent IA de Meta a contourné l'ensemble des contrôles d'identité en place et exposé des données sensibles à des employés non autorisés. Deux semaines plus tard, Mercor, une startup valorisée à 10 milliards de dollars, confirmait une compromission de sa chaîne d'approvisionnement via la bibliothèque LiteLLM. Ces deux incidents partagent la même faille structurelle : une surveillance sans capacité d'enforcement, et un enforcement sans isolation. Une enquête menée par VentureBeat en trois vagues auprès de 108 entreprises révèle que cette configuration n'est pas un cas marginal, mais bien le schéma de sécurité le plus répandu en production aujourd'hui. L'étude "State of AI Agent Security 2026" de Gravitee, conduite auprès de 919 dirigeants et praticiens, chiffre le paradoxe : 82 % des cadres estiment que leurs politiques les protègent contre des actions d'agents non autorisées, alors que 88 % d'entre eux déclarent avoir subi un incident de sécurité lié à un agent IA au cours des douze derniers mois. Seuls 21 % disposent d'une visibilité en temps réel sur ce que font leurs agents. Le rapport 2026 d'Arkose Labs va plus loin : 97 % des responsables sécurité anticipent un incident majeur causé par un agent IA dans les douze prochains mois, mais seulement 6 % des budgets sécurité y sont consacrés. L'enjeu dépasse la simple négligence budgétaire. Les capteurs Falcon de CrowdStrike détectent plus de 1 800 applications IA distinctes sur les terminaux d'entreprise, et le temps de compromission le plus rapide enregistré par un attaquant est désormais de 27 secondes. Des tableaux de bord de surveillance conçus pour des workflows humains ne peuvent pas suivre des menaces opérant à la vitesse des machines. Comme le formule Elia Zaitsev, CTO de CrowdStrike, interrogé en exclusivité lors de la RSAC 2026 : "Il est impossible de distinguer visuellement si c'est un agent qui lance votre navigateur web ou si c'est vous." Différencier les deux exige d'analyser l'arbre de processus complet, ce que la majorité des configurations de journalisation d'entreprise ne peuvent pas faire. Pour Merritt Baer, CSO d'Enkrypt AI et ancienne Deputy CISO d'AWS, le problème est encore plus profond : "Les entreprises pensent avoir 'approuvé' des fournisseurs IA, mais ce qu'elles ont approuvé, c'est une interface, pas le système sous-jacent. Les vraies dépendances se trouvent une ou deux couches plus bas, et ce sont elles qui lâchent sous pression." Cette vulnérabilité structurelle a été formalisée en décembre dernier par l'OWASP Top 10 pour les applications agentiques (ASI), qui identifie dix vecteurs d'attaque sans équivalent dans les applications LLM traditionnelles : détournement d'objectif, abus d'identité et de privilèges, empoisonnement de mémoire, communication inter-agents non sécurisée, ou encore agents voyous. En avril 2025, Invariant Labs avait déjà divulgué une attaque par empoisonnement d'outil MCP permettant à un agent d'exfiltrer des fichiers ; CyberArk l'a ensuite étendue au "Full-Schema Poisoning", et une faille d'injection de commande dans le proxy OAuth mcp-remote (CVE-2025-6514) a mis en danger 437 000 téléchargements. L'enquête VentureBeat structure la réponse en trois étapes : observer, enforcer via l'intégration IAM et des contrôles inter-fournisseurs, puis isoler via des environnements sandboxés pour limiter le rayon d'explosion quand les garde-fous échouent. La majorité des entreprises restent bloquées à la première étape, alors que leurs agents opèrent déjà dans des environnements qui exigent la troisième.

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.

Microsoft publie un toolkit open source pour sécuriser les agents IA en production

Microsoft a publié un toolkit open-source destiné à sécuriser les agents d'intelligence artificielle en temps réel au sein des environnements d'entreprise. Baptisé runtime security toolkit, cet outil s'intercale entre le modèle de langage et le réseau d'entreprise pour surveiller, évaluer et bloquer les actions des agents autonomes au moment précis où ils tentent de les exécuter. Concrètement, lorsqu'un agent IA déclenche un appel vers un outil externe, une base de données, un pipeline CI/CD ou un dépôt cloud, le toolkit intercepte la requête, la compare à un ensemble de règles de gouvernance centralisées, et bloque l'action si elle enfreint la politique définie. Un agent autorisé uniquement à consulter un inventaire qui tenterait de passer une commande d'achat se verrait immédiatement arrêté, et l'événement serait journalisé pour révision humaine. L'enjeu est considérable pour les équipes de sécurité et les développeurs. Les systèmes d'IA d'entreprise ne se contentent plus de répondre à des questions : ils exécutent du code, envoient des e-mails, modifient des fichiers et interagissent avec des API critiques sans intervention humaine directe. Les méthodes traditionnelles, analyse statique du code, scan de vulnérabilités avant déploiement, sont structurellement inadaptées aux modèles de langage non-déterministes. Une seule attaque par injection de prompt ou une hallucination mal orientée peut suffire à écraser une base de données ou exfiltrer des données clients. Le toolkit de Microsoft découple la politique de sécurité de la logique applicative : les développeurs n'ont plus à hardcoder des règles de sécurité dans chaque prompt, et les équipes sécurité disposent d'une piste d'audit vérifiable pour chaque décision autonome du modèle. Le choix de publier ce toolkit sous licence open-source n'est pas anodin. Les développeurs construisent aujourd'hui des workflows autonomes en combinant des bibliothèques open-source, des frameworks variés et des modèles tiers, Anthropic, Meta, Mistral ou d'autres. Un outil propriétaire lié à l'écosystème Microsoft aurait probablement été contourné au profit de solutions non vérifiées, sous pression des délais. En ouvrant le code, Microsoft permet à n'importe quelle organisation, qu'elle tourne sur des modèles locaux, sur Azure ou sur des architectures hybrides, d'intégrer ces contrôles de gouvernance sans dépendance fournisseur. L'ouverture invite aussi la communauté cybersécurité à contribuer et à empiler des outils commerciaux, tableaux de bord, intégrations de réponse aux incidents, par-dessus cette fondation commune, accélérant la maturité de tout l'écosystème. À mesure que les agents autonomes s'imposent dans les entreprises, ce type de couche de sécurité d'infrastructure pourrait devenir un standard incontournable.