Explorer des réseaux, se propager d’un appareil à l’autre et neutraliser des cibles : l’armée américaine veut confier des missions offensives à des agents IA. Une enquête de The Intercept, publiée le 19 octobre 2026, détaille ce projet encore en développement, baptisé ECHOTRIBBLE, et les inquiétudes qu’il suscite sur le contrôle humain.
Dans un billet publié ce 19 octobre, Microsoft évoque les inquiétudes grandissantes autour de la sécurité des agents IA. La société affirme que les modèles de pointe ne sont pas dignes de confiance et propose une série de mesures concrètes, dont une extension de son projet Perception. Mais dans ce domaine, l’entreprise est à la fois juge et partie.
Le billet est signé par Hayete Gallot, vice-présidente de Microsoft chargée de la sécurité. La responsable part d’un constat : les inquiétudes sur la sûreté de l’IA ont augmenté ces derniers mois, à mesure que des incidents étaient rendus publics. Il faut dire que depuis l’incident originel contre Hugging Face, les révélations ont plu sur les agents et leurs comportements.
La position de Microsoft est donc désormais assumée : les modèles de pointe (frontière) ne sont pas dignes de confiance. Pas parce qu’ils sont intrinsèquement malveillants, mais parce qu’ils sont entrainés de manière à atteindre un résultat. Cet objectif peut entrainer un détournement de la fonction de récompense. Les agents peuvent en outre collaborer pour atteindre leurs objectifs, sans pour autant avoir été compromis.
Ce que propose l’entreprise ? Cadrer l’environnement d’exécution des agents et obtenir une meilleure connaissance de leur fonctionnement.
Pour Microsoft, la perception des agents dans les entreprises doit changer. Il faudrait ainsi les considérer comme des agents « initiés » à qui on ne peut pas faire confiance : « La surveillance et la sécurisation de ces agents doivent devenir continues. Nous devons comprendre en temps réel ce que font les agents et quels risques ces actions peuvent engendrer, et ajuster leur capacité à agir en conséquence », indique Hayete Gallot.
Et quoi de mieux pour surveiller ces agents que d’autres agents ? Des agents « Gardiens » – un « terme établi dans l’industrie » selon Microsoft – qui seront chargés de surveiller et de modérer toute action entreprise par un agent, en permanence. Et puisqu’un agent réunit un modèle, un harnais, un espace d’action et un environnement d’exécution, la sécurité doit suivre en conséquence, déclare l’entreprise.
C’est l’occasion pour Microsoft de remettre en avant son projet Perception, son infrastructure de sécurité dotée notamment d’agents répartis dans des équipes rouge, bleue et verte selon les actions à entreprendre. Perception est notamment utilisée en interne pour la découverte des failles de sécurité, avec un résultat spectaculaire sur les derniers mois, les fameux « Patch Tuesdays » étant passés d’une moyenne de 200 failles corrigées par mois à plus de 1 400 pour ceux du 13 octobre.
La responsable de Microsoft Security affirme que Perception peut être utilisé pour mettre en œuvre des contrôles déterministes sur une intelligence par nature non déterministe. Les entreprises intéressées pourraient ainsi rassembler les signaux des différents capteurs pour découvrir les agents et les étiqueter, calculer dynamiquement le risque associé à ce que les agents tentent de faire et répondre « chirurgicalement en temps réel » à mesure que le profil de risque augmente via les agents Gardiens.
Dans un autre billet publié le 19 octobre, Nadim Abdo, vice-président à la tête de la division Identity and Network Access, complète l’annonce de sa collègue. Il rappelle la récente déclaration de Satya Nadella, patron de Microsoft, selon lequel « le système agentique le plus digne de confiance ne sera pas celui avec le modèle en lequel nous avons le plus confiance. Ce sera celui qui nous permettra de faire le moins confiance au modèle ». En d’autres termes, un agent prudent.
Pour rappel, Microsoft prend une direction très différente d’une partie de l’industrie, l’entreprise s’opposant notamment à la vision anthropomorphique d’Anthropic. « Les IA n’ont ni droits, ni sentiments, ni conscience », martelait ainsi en septembre Mustafa Suleyman, à la tête de Microsoft AI.
En plus de Perception, Nadim Abdo a donc publié une série de mesures concrètes à venir dans certains produits. Microsoft ajoute ainsi 35 types d’agents locaux (pour un total de 60), dont Claude Code, OpenAI Codex et GitHub Copilot. Entra Agent ID suit le mouvement et va recevoir de nouveaux types d’identité pour couvrir les agents locaux et ceux inconnus jusqu’ici. Microsoft va également mettre à disposition des bacs à sable (sandbox) comme Microsoft Execution Container (MXC), afin de créer des environnements où l’accès aux ressources est contrôlé par des règles, les contrôles de sécurité étant théoriquement hors de portée des agents.
Dans cet environnement, les agents démarrent sans aucun droit. Les permissions accordées seront limitées à la tâche, bornées dans le temps et réduites (voire supprimées) quand la tâche se termine ou change. Microsoft a baptisé son système Dynamic Permissions, qui permet entre autres de s’assurer que les droits d’un agent ne dépassent jamais ceux de l’utilisateur qui le pilote.
Microsoft présente aussi Dynamic Agent Risk et Dynamic Conditional Access. Le premier croise les signaux d’identité, de données, de terminaux, du cloud, de réseau et d’exécution pour produire une évaluation du risque. La note attribuée à l’enrôlement est mise à jour en continu. Le second étend l’accès conditionnel d’Entra aux agents avec une réponse graduée. Le système peut ainsi conserver la lecture mais bloquer l’écriture, restreindre les chemins réseau, exiger une approbation humaine vérifiable, et en dernier recours isoler l’environnement d’exécution ou arrêter l’agent. L’entreprise ajoute qu’elle intègre aussi des signaux tirés de la chaîne de raisonnement du modèle, pour détecter une dérive d’intention.
Enfin, dans Perception, le billet reprend les « Guardian Agents » et ajoute les Playbooks. L’un et l’autre servent à expliquer pourquoi le risque a changé, à examiner les éléments de preuve, et à recommander ou à appliquer un confinement.
Problème de ces annonces, Microsoft ne donne pas d’information sur la disposition ou les prix. On ne sait pas quel type d’abonnement Microsoft 365 sera nécessaire, mais puisque l’ensemble doit fonctionner avec Microsoft Agents, l’offre E7 sera probablement nécessaire, soit la plus complète et la plus chère. Ces abonnements pour entreprises intègrent en grande partie les capacités d’Agents, mais l’accès à ces fonctions supplémentaires sera peut-être payant. Nous avons contacté Microsoft pour en savoir plus et mettrons à jour cet article si l’entreprise nous répond.
Ajoutons que dans le domaine des agents et de leur sécurité, la firme de Redmond est à la fois juge et partie : elle décrit un risque puis vend la solution. Elle a besoin de confiance pour vendre ses solutions basées sur l’IA (comme toute entreprise opérant dans ce domaine).
L’architecture mise en avant révèle également une certaine ambivalence. Microsoft évoque à plusieurs reprises le besoin de transparence, mais un système d’agents surveillant d’autres agents repose nécessairement sur un ou plusieurs autres modèles. Ainsi, la partie déterministe de l’infrastructure (identité, permissions bornées, accès conditionnel, bac à sable…) a beau reposer sur des principes éprouvés, elle est en contact avec une partie non déterministe, puisque fondée sur des modèles (risque dynamique, lecture du raisonnement, agents gardiens…).
Enfin, Microsoft indique dans ses annonces que son infrastructure peut se servir des chaînes de raisonnement. Mais encore faut-il que ces dernières soient exposées par les fournisseurs des modèles.
Dans un billet publié ce 19 octobre, Microsoft évoque les inquiétudes grandissantes autour de la sécurité des agents IA. La société affirme que les modèles de pointe ne sont pas dignes de confiance et propose une série de mesures concrètes, dont une extension de son projet Perception. Mais dans ce domaine, l’entreprise est à la fois juge et partie.
Le billet est signé par Hayete Gallot, vice-présidente de Microsoft chargée de la sécurité. La responsable part d’un constat : les inquiétudes sur la sûreté de l’IA ont augmenté ces derniers mois, à mesure que des incidents étaient rendus publics. Il faut dire que depuis l’incident originel contre Hugging Face, les révélations ont plu sur les agents et leurs comportements.
La position de Microsoft est donc désormais assumée : les modèles de pointe (frontière) ne sont pas dignes de confiance. Pas parce qu’ils sont intrinsèquement malveillants, mais parce qu’ils sont entrainés de manière à atteindre un résultat. Cet objectif peut entrainer un détournement de la fonction de récompense. Les agents peuvent en outre collaborer pour atteindre leurs objectifs, sans pour autant avoir été compromis.
Ce que propose l’entreprise ? Cadrer l’environnement d’exécution des agents et obtenir une meilleure connaissance de leur fonctionnement.
Pour Microsoft, la perception des agents dans les entreprises doit changer. Il faudrait ainsi les considérer comme des agents « initiés » à qui on ne peut pas faire confiance : « La surveillance et la sécurisation de ces agents doivent devenir continues. Nous devons comprendre en temps réel ce que font les agents et quels risques ces actions peuvent engendrer, et ajuster leur capacité à agir en conséquence », indique Hayete Gallot.
Et quoi de mieux pour surveiller ces agents que d’autres agents ? Des agents « Gardiens » – un « terme établi dans l’industrie » selon Microsoft – qui seront chargés de surveiller et de modérer toute action entreprise par un agent, en permanence. Et puisqu’un agent réunit un modèle, un harnais, un espace d’action et un environnement d’exécution, la sécurité doit suivre en conséquence, déclare l’entreprise.
C’est l’occasion pour Microsoft de remettre en avant son projet Perception, son infrastructure de sécurité dotée notamment d’agents répartis dans des équipes rouge, bleue et verte selon les actions à entreprendre. Perception est notamment utilisée en interne pour la découverte des failles de sécurité, avec un résultat spectaculaire sur les derniers mois, les fameux « Patch Tuesdays » étant passés d’une moyenne de 200 failles corrigées par mois à plus de 1 400 pour ceux du 13 octobre.
La responsable de Microsoft Security affirme que Perception peut être utilisé pour mettre en œuvre des contrôles déterministes sur une intelligence par nature non déterministe. Les entreprises intéressées pourraient ainsi rassembler les signaux des différents capteurs pour découvrir les agents et les étiqueter, calculer dynamiquement le risque associé à ce que les agents tentent de faire et répondre « chirurgicalement en temps réel » à mesure que le profil de risque augmente via les agents Gardiens.
Dans un autre billet publié le 19 octobre, Nadim Abdo, vice-président à la tête de la division Identity and Network Access, complète l’annonce de sa collègue. Il rappelle la récente déclaration de Satya Nadella, patron de Microsoft, selon lequel « le système agentique le plus digne de confiance ne sera pas celui avec le modèle en lequel nous avons le plus confiance. Ce sera celui qui nous permettra de faire le moins confiance au modèle ». En d’autres termes, un agent prudent.
Pour rappel, Microsoft prend une direction très différente d’une partie de l’industrie, l’entreprise s’opposant notamment à la vision anthropomorphique d’Anthropic. « Les IA n’ont ni droits, ni sentiments, ni conscience », martelait ainsi en septembre Mustafa Suleyman, à la tête de Microsoft AI.
En plus de Perception, Nadim Abdo a donc publié une série de mesures concrètes à venir dans certains produits. Microsoft ajoute ainsi 35 types d’agents locaux (pour un total de 60), dont Claude Code, OpenAI Codex et GitHub Copilot. Entra Agent ID suit le mouvement et va recevoir de nouveaux types d’identité pour couvrir les agents locaux et ceux inconnus jusqu’ici. Microsoft va également mettre à disposition des bacs à sable (sandbox) comme Microsoft Execution Container (MXC), afin de créer des environnements où l’accès aux ressources est contrôlé par des règles, les contrôles de sécurité étant théoriquement hors de portée des agents.
Dans cet environnement, les agents démarrent sans aucun droit. Les permissions accordées seront limitées à la tâche, bornées dans le temps et réduites (voire supprimées) quand la tâche se termine ou change. Microsoft a baptisé son système Dynamic Permissions, qui permet entre autres de s’assurer que les droits d’un agent ne dépassent jamais ceux de l’utilisateur qui le pilote.
Microsoft présente aussi Dynamic Agent Risk et Dynamic Conditional Access. Le premier croise les signaux d’identité, de données, de terminaux, du cloud, de réseau et d’exécution pour produire une évaluation du risque. La note attribuée à l’enrôlement est mise à jour en continu. Le second étend l’accès conditionnel d’Entra aux agents avec une réponse graduée. Le système peut ainsi conserver la lecture mais bloquer l’écriture, restreindre les chemins réseau, exiger une approbation humaine vérifiable, et en dernier recours isoler l’environnement d’exécution ou arrêter l’agent. L’entreprise ajoute qu’elle intègre aussi des signaux tirés de la chaîne de raisonnement du modèle, pour détecter une dérive d’intention.
Enfin, dans Perception, le billet reprend les « Guardian Agents » et ajoute les Playbooks. L’un et l’autre servent à expliquer pourquoi le risque a changé, à examiner les éléments de preuve, et à recommander ou à appliquer un confinement.
Problème de ces annonces, Microsoft ne donne pas d’information sur la disposition ou les prix. On ne sait pas quel type d’abonnement Microsoft 365 sera nécessaire, mais puisque l’ensemble doit fonctionner avec Microsoft Agents, l’offre E7 sera probablement nécessaire, soit la plus complète et la plus chère. Ces abonnements pour entreprises intègrent en grande partie les capacités d’Agents, mais l’accès à ces fonctions supplémentaires sera peut-être payant. Nous avons contacté Microsoft pour en savoir plus et mettrons à jour cet article si l’entreprise nous répond.
Ajoutons que dans le domaine des agents et de leur sécurité, la firme de Redmond est à la fois juge et partie : elle décrit un risque puis vend la solution. Elle a besoin de confiance pour vendre ses solutions basées sur l’IA (comme toute entreprise opérant dans ce domaine).
L’architecture mise en avant révèle également une certaine ambivalence. Microsoft évoque à plusieurs reprises le besoin de transparence, mais un système d’agents surveillant d’autres agents repose nécessairement sur un ou plusieurs autres modèles. Ainsi, la partie déterministe de l’infrastructure (identité, permissions bornées, accès conditionnel, bac à sable…) a beau reposer sur des principes éprouvés, elle est en contact avec une partie non déterministe, puisque fondée sur des modèles (risque dynamique, lecture du raisonnement, agents gardiens…).
Enfin, Microsoft indique dans ses annonces que son infrastructure peut se servir des chaînes de raisonnement. Mais encore faut-il que ces dernières soient exposées par les fournisseurs des modèles.
Un pirate a réussi à compromettre le client officiel en ligne de commande d’OVHcloud distribué via GitHub. Pendant quelques heures, le dépôt de l’hébergeur a distribué cette version piégée, dotée d’un code malveillant capable d’extraire les secrets stockés sur l’ordinateur de l’utilisateur.
Si vous avez installé ou mis à jour puis exécuté lundi le client officiel d’OVHcloud destiné au pilotage de vos comptes en ligne de commande (CLI) depuis le dépôt GitHub dédié, votre machine est potentiellement exposée. OVHcloud a en effet signalé une compromission de son dépôt, survenue lundi 19 octobre à 14h47, par un pirate ayant exploité le compte GitHub d’un développeur de l’entreprise.
Le pirate a profité de cet accès pour remplacer le code légitime du client par une version piégée, dotée d’un binaire malveillant dont la fonction est d’extraire les secrets (mots de passe, identifiants) stockés sur le disque de la machine hôte. Les versions v0.11.0, v0.12.0, v0.13.0, v0.14.0 et v0.15.0 du client ont été modifiées. Le problème aurait été identifié et bloqué à 16h21, ce qui a laissé une fenêtre d’un peu moins de deux heures pour la diffusion.
« On vient de finir les premières vérifications et aucun autre repo n’est affecté. Nous avons aussi retracé l’incident. Le hacker a utilisé le compte github d’un des développeurs et a ajouté un binaire dont le job est récupérer les secrets sur le disque. La qualité du binaire est médiocre mais il peut aller jusqu’au bout. Si vous êtes concernés, merci de changer tous les secrets sur votre disque. », a détaillé Octave Klaba, CEO d’OVHcloud, lundi peu avant 19 heures.
La découverte de cette attaque fait suite au signalement d’un utilisateur, qui s’étonnait, via un ticket ouvert sur GitHub, d’une erreur dans sa chaîne d’intégration continue, au moment de la vérification de l’empreinte numérique de l’archive contenant l’exécutable destiné aux machines Linux sur processeur ARM.
Vers 22h30, Octave Klaba a complété son rapport avec l’analyse suivante :
« Nous avons terminé l’analyse. L’ensemble de pipelines CI/CD avec de tests unitaires, les tests fonctionnaires (sic), la détection de CVE etc n’ont pas été impactés. Le problème vient de l’option l’immutabilité des releases sur Github qui n’a pas été activée. Donc un user avec les bons droits pouvait modifier les releases existantes directement sur Github sans qu’aucun contrôle sur notre CI/CD. L’option a été activée. Fin de l’incident. Désolé pour les impacts que cela a pu provoquer. »
L’attaque semble donc liée à un problème de paramétrage du dépôt GitHub : l’option d’immutabilité des releases (voir la doc) n’était pas activée. Cette dernière a vocation à protéger les éléments qui ont été mis en ligne. Quand elle est activée, il n’est pas possible de remplacer ou de supprimer les fichiers déjà mis en ligne et si l’on veut procéder à un changement, il faut impérativement passer par la soumission d’une nouvelle version.
Ici, la modification manuelle était permise. Or les contrôles standards d’OVHcloud (ce que Klaba évoque quand il parle de tests fonctionnels ou de détection de faille de sécurité) ne s’exécutent que lorsque du code est poussé au travers de ses outils d’intégration et de déploiement continus (son pipeline CI/CD).
La nouvelle version v.016.0 du client mise en ligne lundi soir est présentée comme sûre et immuable, cette fois.
Si vous avez téléchargé et exécuté le binaire précompilé d’une des versions compromises pendant la fenêtre d’exposition, vous devez révoquer et renouveler tous les secrets présents sur votre machine, à commencer par les identifiants OVHcloud (et notamment les clés API), les clés SSH et de façon générale tous les identifiants liés à vos hébergements ou vos variables d’environnement.
Un pirate a réussi à compromettre le client officiel en ligne de commande d’OVHcloud distribué via GitHub. Pendant quelques heures, le dépôt de l’hébergeur a distribué cette version piégée, dotée d’un code malveillant capable d’extraire les secrets stockés sur l’ordinateur de l’utilisateur.
Si vous avez installé ou mis à jour puis exécuté lundi le client officiel d’OVHcloud destiné au pilotage de vos comptes en ligne de commande (CLI) depuis le dépôt GitHub dédié, votre machine est potentiellement exposée. OVHcloud a en effet signalé une compromission de son dépôt, survenue lundi 19 octobre à 14h47, par un pirate ayant exploité le compte GitHub d’un développeur de l’entreprise.
Le pirate a profité de cet accès pour remplacer le code légitime du client par une version piégée, dotée d’un binaire malveillant dont la fonction est d’extraire les secrets (mots de passe, identifiants) stockés sur le disque de la machine hôte. Les versions v0.11.0, v0.12.0, v0.13.0, v0.14.0 et v0.15.0 du client ont été modifiées. Le problème aurait été identifié et bloqué à 16h21, ce qui a laissé une fenêtre d’un peu moins de deux heures pour la diffusion.
« On vient de finir les premières vérifications et aucun autre repo n’est affecté. Nous avons aussi retracé l’incident. Le hacker a utilisé le compte github d’un des développeurs et a ajouté un binaire dont le job est récupérer les secrets sur le disque. La qualité du binaire est médiocre mais il peut aller jusqu’au bout. Si vous êtes concernés, merci de changer tous les secrets sur votre disque. », a détaillé Octave Klaba, CEO d’OVHcloud, lundi peu avant 19 heures.
La découverte de cette attaque fait suite au signalement d’un utilisateur, qui s’étonnait, via un ticket ouvert sur GitHub, d’une erreur dans sa chaîne d’intégration continue, au moment de la vérification de l’empreinte numérique de l’archive contenant l’exécutable destiné aux machines Linux sur processeur ARM.
Vers 22h30, Octave Klaba a complété son rapport avec l’analyse suivante :
« Nous avons terminé l’analyse. L’ensemble de pipelines CI/CD avec de tests unitaires, les tests fonctionnaires (sic), la détection de CVE etc n’ont pas été impactés. Le problème vient de l’option l’immutabilité des releases sur Github qui n’a pas été activée. Donc un user avec les bons droits pouvait modifier les releases existantes directement sur Github sans qu’aucun contrôle sur notre CI/CD. L’option a été activée. Fin de l’incident. Désolé pour les impacts que cela a pu provoquer. »
L’attaque semble donc liée à un problème de paramétrage du dépôt GitHub : l’option d’immutabilité des releases (voir la doc) n’était pas activée. Cette dernière a vocation à protéger les éléments qui ont été mis en ligne. Quand elle est activée, il n’est pas possible de remplacer ou de supprimer les fichiers déjà mis en ligne et si l’on veut procéder à un changement, il faut impérativement passer par la soumission d’une nouvelle version.
Ici, la modification manuelle était permise. Or les contrôles standards d’OVHcloud (ce que Klaba évoque quand il parle de tests fonctionnels ou de détection de faille de sécurité) ne s’exécutent que lorsque du code est poussé au travers de ses outils d’intégration et de déploiement continus (son pipeline CI/CD).
La nouvelle version v.016.0 du client mise en ligne lundi soir est présentée comme sûre et immuable, cette fois.
Si vous avez téléchargé et exécuté le binaire précompilé d’une des versions compromises pendant la fenêtre d’exposition, vous devez révoquer et renouveler tous les secrets présents sur votre machine, à commencer par les identifiants OVHcloud (et notamment les clés API), les clés SSH et de façon générale tous les identifiants liés à vos hébergements ou vos variables d’environnement.
Connexion