En bref
- 1Password a présenté le 22 octobre un système où l'agent IA s'authentifie avec une clé numérique propre, le gestionnaire remplit le formulaire et retire l'identifiant dès la connexion validée.
- Microsoft attribue à Storm-0940 l'usage du framework ARTEX, un outil agentique basé sur Go, pour tenter plus de 2 250 connexions sur 2 900 tentatives par minute lors de la compromission de ConnectWise Cloud Backup.
- OpenShell, un runtime publié sous licence Apache 2.0, applique les politiques d'accès au niveau du noyau et vérifie formellement chaque changement de politique avant application.
- Yelp, Delta Air Lines, JPMorgan Chase et Charles Schwab bloquent les agents IA, et Amazon a poursuivi Perplexity en justice pour son agent d'achat.
Point d'inflexion
Les agents IA ne sont plus des démonstrations. Ils se connectent à des comptes réels, manipulent des identifiants et déclenchent des actions chez des tiers. La question de leur sécurité a donc changé de nature. Elle ne porte plus sur le contenu de leurs réponses mais sur les droits qu'on leur concède et sur la manière de les révoquer.
Trois sources décrivent trois réponses techniques à ce même problème. 1Password traite l'identité de l'agent comme une identité déléguée distincte de celle de l'utilisateur. OpenShell traite l'exécution de l'agent comme un environnement à confiner au niveau du noyau. Microsoft documente ce qui arrive quand un adversaire retourne ces mêmes mécanismes contre des victimes. Le quatrième texte, sur le blocage des agents par les sites web, montre que la couche applicative refuse déjà de coopérer.
Mon hypothèse est que la sécurisation des agents va se jouer sur la durée de vie des accès plus que sur leur portée. Un jeton qui expire en quelques secondes pose moins de risque qu'un jeton permanent même très restreint. Les quatre textes convergent vers cette idée sans la formuler explicitement.
État de l'art et tendances majeures
Identités déléguées et secrets éphémères
Le mécanisme décrit par 1Password repose sur une séparation nette entre l'agent et le coffre. L'agent s'identifie auprès du gestionnaire avec une clé numérique qui lui est propre. L'utilisateur voit quel identifiant est demandé et dans quel but puis accepte ou refuse sur un appareil autorisé. Si l'accord est donné, 1Password remplit lui-même le formulaire et retire l'identifiant dès que le site valide la connexion. La société affirme que l'agent ne peut ni lire le secret ni le réutiliser, et que le reste du coffre demeure chiffré de bout en bout.
La limite est explicite dans la foire aux questions de l'entreprise. Une fois connecté au compte de la compagnie aérienne ou du site marchand, l'agent peut consulter des informations et agir dessus. 1Password recommande de vérifier la tâche et le compte avant d'approuver. Le risque se déplace donc du gestionnaire vers le périmètre du compte cible.
OpenShell applique une logique voisine sur un autre plan. Les agents ne voient jamais les vrais identifiants. Le runtime les ajoute uniquement aux requêtes destinées à des points de terminaison approuvés. Le secret n'est plus détenu par l'agent mais injecté par l'infrastructure au dernier moment.
Confinement d'exécution et vérification formelle
OpenShell instrumente le noyau pour appliquer la politique à chaque accès fichier, appel système et connexion réseau. Chaque agent tourne dans un bac à sable isolé et toute connexion sortante passe un contrôle de politique avant de quitter cet espace. Le runtime ajoute une seconde couche avec la vérification formelle. Avant qu'un changement de politique soit approuvé, le système signale les nouveaux accès risqués qu'il accorderait, comme joindre un nouvel hôte avec des identifiants ou appeler une nouvelle méthode d'API. Ces changements attendent une revue humaine.
Cette combinaison répond à un angle mort classique des politiques d'agents. Une politique écrite à la main dérive avec le temps et personne ne sait plus ce qu'elle autorise réellement. La vérification formelle rend cet effet de bord visible avant application. Cela reste à surveiller sur un point : la vérification porte sur la politique, pas sur le comportement de l'agent. Un agent qui respecte sa politique peut toujours nuire dans les limites qu'elle fixe.
Quand l'adversaire utilise les mêmes outils
Microsoft documente le revers de la médaille. Storm-0940 a utilisé ARTEX pour automatiser reconnaissance, pulvérisation de mots de passe et abus d'applications OAuth chez des victimes en aval. Entre le 10 et le 14 octobre 2026, l'infrastructure de l'attaquant a ciblé 327 comptes dans huit organisations et Microsoft a capté plus de 151 000 échecs de connexion, avec un pic à 2 900 échecs par minute le 11 octobre. Aucune authentification réussie n'a été détectée sur cette période.
La situation change le 15 octobre 2026 quand les agents obtiennent l'accès aux identités de plusieurs applications cloud de ConnectWise. Ils s'en servent pour s'authentifier auprès des environnements clients en réutilisant la confiance déjà établie par ces applications dans chaque locataire. Microsoft note que certaines attaques ont abouti à un accès privilégié en moins de trois heures. La modification des identifiants d'application peut survivre à la remédiation de l'application compromise et servir de porte dérobée.
Zscaler ThreatLabz a analysé un déploiement ARTEX configuré avec un modèle DeepSeek derrière une passerelle compatible OpenAI, avec d'autres configurations citant DeepSeek, GLM et Grok. Les invites demandaient aux modèles de se répartir les tâches d'investigation et de relire mutuellement leurs résultats. Wiz a observé des sessions de 24 à 30 heures et de nouvelles adresses IP quelques minutes après un blocage.
Architectures et outils
| Critère | 1Password | OpenShell | ARTEX (usage offensif) |
|---|---|---|---|
| Objet protégé | Identifiants du coffre | Fichiers, appels système, réseau | Identités d'applications cloud |
| Mécanisme | Clé numérique propre à l'agent, remplissage par le gestionnaire | Bac à sable noyau et passerelle de politique | Automatisation de la reconnaissance et de l'authentification |
| Durée de l'accès | Retrait de l'identifiant dès la connexion validée | Injection des identifiants par requête | Réutilisation d'une confiance déjà accordée |
| Contrôle humain | Approbation sur un appareil autorisé | Revue des changements signalés par la vérification formelle | Aucun |
| Périmètre couvert | Comptes hébergés sur 1Password.com uniquement | Linux, macOS Apple Silicon, Windows avec WSL 2 | Plusieurs secteurs et régions |
Le tableau met en évidence une asymétrie. Les deux outils défensifs limitent la portée ou la durée d'un accès. L'outil offensif exploite des accès déjà accordés et ne demande jamais de nouvelle autorisation. La leçon pour un architecte est que la surface d'attaque se trouve dans les intégrations existantes, pas dans les nouvelles.
Impact concret sur le workflow professionnel
Pour un développeur qui construit un agent, la première conséquence est qu'il faut traiter l'agent comme un principal d'identité à part entière. Cela implique des identifiants distincts, une journalisation par agent et une procédure de révocation qui ne passe pas par le compte de l'utilisateur. Le modèle de 1Password montre qu'un gestionnaire peut jouer ce rôle d'intermédiaire sans exposer le secret à l'agent.
La deuxième conséquence concerne l'environnement d'exécution. OpenShell impose Docker, Podman ou la virtualisation hôte, et un CNI qui applique NetworkPolicy pour un déploiement Kubernetes. Ce sont des contraintes d'infrastructure réelles, pas des options. Une équipe qui déploie des flottes d'agents doit prévoir cette couche dès le départ.
La troisième conséquence touche les intégrations côté fournisseur. Les sites bloquent déjà les agents. Yelp réserve l'accès aux agents qui paient son programme de licence de données, Delta Air Lines empêche la réservation de billets, JPMorgan Chase et Charles Schwab bloquent l'accès aux comptes pour raisons de sécurité. Meta a répondu en s'appuyant sur des partenariats avec Walmart, Gap, Sephora et Best Buy, et Shopify a ouvert son réseau de boutiques aux agents. Un agent qui échoue sur un site sans accord préalable n'est pas un bug à corriger, c'est un refus commercial.
La quatrième conséquence est défensive. Les modifications d'identifiants d'application observées par Microsoft peuvent persister après la remédiation. Une équipe qui répond à un incident doit auditer les identifiants d'application et les rôles privilégiés, pas seulement réinitialiser les mots de passe. Le lien entre confinement d'exécution et incidents d'agents est d'ailleurs documenté ailleurs sur ce blog, dans Incidents d'agents IA : des experts pointent des échecs de confinement, pas de la « misalignment ».
Conclusion et perspectives
Les quatre textes décrivent un même déplacement du problème. La sécurité des agents ne se joue plus dans le modèle mais dans les identités qu'on lui prête et dans l'environnement qui l'exécute. 1Password et OpenShell proposent deux réponses complémentaires, l'une sur le secret, l'autre sur le bac à sable. Microsoft montre que ces mécanismes peuvent être retournés et que la fenêtre de détection se compte en heures. Les sites web ajoutent une couche de refus que les agents ne peuvent pas contourner techniquement. Mon hypothèse est que les équipes qui gagneront du temps seront celles qui traiteront la révocation comme une fonctionnalité de premier plan, pas comme une procédure d'urgence.
- Donner à chaque agent une identité distincte et journaliser ses actions séparément de celles de l'utilisateur.
- Faire transiter les secrets par un intermédiaire qui les injecte par requête plutôt que de les stocker dans l'agent.
- Auditer les identifiants d'application et les rôles privilégiés après tout incident, car ces modifications peuvent survivre à la remédiation.
- Vérifier qu'un site cible accepte les agents avant de construire un parcours qui en dépend.
Questions fréquentes
Un agent peut-il lire les mots de passe de mon coffre avec le système de 1Password ?
Non selon l'entreprise. L'agent s'authentifie avec sa propre clé numérique et 1Password remplit le formulaire à sa place. Le gestionnaire retire l'identifiant dès que le site valide la connexion, et le reste du coffre demeure chiffré de bout en bout.
OpenShell empêche-t-il un agent de faire une erreur de jugement ?
Non. Le runtime applique une politique sur les fichiers, les appels système et le réseau. Un agent qui reste dans les limites de sa politique peut toujours prendre une mauvaise décision dans ce périmètre. La vérification formelle signale les nouveaux accès risqués avant application mais ne juge pas l'intention.
Pourquoi les sites web bloquent-ils les agents IA ?
Les raisons diffèrent selon les acteurs. Yelp réserve l'accès aux agents qui paient son programme de licence de données, Delta Air Lines refuse la réservation de billets et JPMorgan Chase comme Charles Schwab invoquent la sécurité des comptes. Amazon a poursuivi Perplexity en justice pour son agent d'achat et soutient que ces accès violent ses règles.
Les agents peuvent-ils contourner les protections anti-robots ?
Ils les déclenchent souvent sans les contourner. Chris Canal, dirigeant d'EquiStamp, explique que les protections mises en place contre les programmes malveillants réagissent de la même manière aux agents IA. Des utilisateurs ont signalé des blocages de comptes Google liés à l'usage de Muse pour activité suspecte.
Ressources complémentaires
- 1Password a un plan pour laisser les agents IA accéder à vos comptes, sans exposer vos mots de passe · Numerama
- Agents IA : 1Password encadre l'utilisation des identifiants · Le Monde Informatique
- China-Linked Hackers Use ARTEX AI Agents in ConnectWise Supply Chain Attack · The Hacker News
- Microsoft Links Storm-0940 to ConnectWise Supply Chain Attack · Dark Reading
- OpenShell – A safe, private runtime for fleets of autonomous AI agents · Hacker News
- Websites are closing their doors to AI agents · The Verge