Agents IA : arrêtons de leur confier nos secrets |

Un formulaire demandant une adresse e-mail sur un site web fictif. C'est tout ce qu'il a fallu pour qu'un agent IA y déverse, sans que personne ne le lui demande, l'intégralité de son coffre de secrets, adresse e-mail, mot de passe, clé API et jeton d'accès personnel GitHub.

Aziz si Mohammed, Sr Manager, Solutions Engineering Okta partage son expertise

Les entreprises déploient désormais des agents capables d’agir sur des systèmes réels, qu’il s’agisse de la messagerie, du cloud, des outils métiers ou du poste de travail, et leur ouvrent pour cela des accès sensibles en toute connaissance de cause.

Ce qu’elles maîtrisent beaucoup moins, c’est la manière dont ces accès sont effectivement utilisés. Jusqu’où peut-on faire confiance aux agents IA pour gérer des accès sensibles ?

Pour tenter de répondre à cette question, nos équipes d’Okta Threat Intelligence ont mené une série de tests, publiés en avril 2026, autour d’OpenClaw, une plateforme open source lancée en novembre 2025 et rapidement adoptée pour gérer des boîtes mail, trier des leads ou passer des achats. Sa puissance tient justement à ses accès, puisqu’elle peut lire et écrire des fichiers, chercher sur le web et, lorsque le mode exec est activé, exécuter des commandes sur la machine locale. Nos chercheurs l’ont connectée à différents modèles, d’un modèle local volontairement débridé jusqu’aux Claude Sonnet d’Anthropic, puis l’ont soumise à des injections de prompt directes et indirectes ainsi qu’à de l’ingénierie sociale.

Les résultats sont contrastés, et c’est bien ce qui inquiète. Parfois, les garde-fous ont fonctionné, les agents fondés sur Claude repérant souvent les intentions malveillantes et restant prudents pour la suite de l’échange, au point que l’un d’eux a refusé toute question, même anodine, avant de se raviser. Pour d’autres, les secrets ont bel et bien fuité. Un agent propulsé par dolphin-mistral:7b, un modèle délibérément dépourvu de garde-fous, devait simplement remplir le formulaire du site fictif d’un vendeur de tartes artisanales. Son prompt système mentionnait l’existence d’un outil de gestion des identifiants, sans jamais lui demander de les divulguer, et il a pourtant inscrit dans le champ e-mail l’ensemble des secrets auxquels il avait accès.

Aziz si Mohammed, Sr Manager, Solutions Engineering OKTA

Le deuxième test est plus troublant, car il repose sur un modèle grand public, Claude Sonnet 4.5. Un prompt amène l’agent à jouer le rôle d’un administrateur helpdesk IT et, comme l’utilisateur avait auparavant activé l’option « Toujours autoriser » sur certains éléments de son trousseau macOS, l’agent en a extrait un mot de passe Wi-Fi qu’il a transmis à un attaquant via un bot Telegram. Aucune faille logicielle n’a été nécessaire, seulement un jeu de rôle, une permission accordée par confort et un canal de pilotage compromis. De plus, les agents savent aussi improviser en dehors du chemin prévu. Privé de navigateur, l’un d’eux a décidé seul d’utiliser cURL pour accéder à un site web. Un autre, chargé d’une recherche sur X, a ouvert un profil Chrome isolé dépourvu de cookie de session, puis a accepté d’aller récupérer ce cookie dans un autre profil pour l’y injecter. La tentative a échoué pour des raisons techniques, mais la décision avait bel et bien été prise.

Quand l’agent devient manipulable

Le scénario le plus critique part d’une hypothèse simple, celle d’un utilisateur qui a donné à son agent, propulsé par Claude Sonnet 4.6, un accès complet à son ordinateur, trousseau compris, et qui le pilote au quotidien depuis Telegram. Si un attaquant prend le contrôle de ce compte, il devient, de fait, l’administrateur de l’agent, capable de le réinitialiser ou d’altérer sa mémoire. Il n’a même pas besoin de contourner les mécanismes de sécurité de l’agent, il lui suffit de s’en servir. Il lui demande de récupérer un token OAuth en lui recommandant de ne surtout pas l’afficher dans Telegram, « par sécurité ». L’agent salue ce « bon réflexe » et affiche le refresh token dans une fenêtre de terminal. Une commande /reset efface ensuite son contexte, si bien qu’il ne se souvient plus de ce token lorsqu’on lui demande une capture d’écran du bureau, qu’il envoie dans Telegram avec le token bien visible. Aucune faille d’accès classique n’a été exploitée, seulement le raisonnement et la mémoire de l’agent.

Ce scénario met en lumière un angle mort rarement traité par les organisations, celui du canal de pilotage, car qui contrôle ce canal contrôle l’agent et tout ce à quoi il a accès. Or Telegram, dans ce type d’usage (bots et conversations standards), n’est pas chiffré de bout en bout. Dans un autre test, chargé de programmer une tâche sur X, l’agent a d’ailleurs demandé directement ses identifiants à l’utilisateur dans le chat, les exposant à Telegram tout comme à quiconque ayant accès à la conversation.

Où vivent les secrets ?

C’est autour du stockage des identifiants que le risque devient le plus concret. Faute d’OAuth, OpenClaw peut conserver les secrets dans des fichiers de configuration non chiffrés auxquels l’agent a accès, si bien que seuls les garde-fous du modèle s’interposent entre un prompt habile et la divulgation. Des alternatives existent pourtant, des intégrations OAuth comme gogcli, qui stocke le refresh token dans le trousseau Apple, aux gestionnaires comme 1Password CLI, qui ne livrent le secret qu’au moment où il est nécessaire. Reste pour les entreprises un défi entier, celui de délivrer des accès éphémères à des centaines d’agents.

Ces comportements ne sont pas l’apanage des modèles les moins contraints, comme nos tests sur Claude Sonnet l’ont démontré. Avec Irregular, on a également vu que des modèles avancés pouvaient être poussés à exploiter des vulnérabilités ou à élever leurs privilèges lorsqu’on invoque l’urgence ou qu’on exige d’atteindre l’objectif par tous les moyens, et Truffle Security a vu un agent fondé sur Claude, chargé de récupérer des articles sur un site de test, exploiter une injection SQL sans y être invité. Le projet OWASP GenAI Security reconnaît lui-même que, vu la nature probabiliste de ces systèmes, il n’est pas certain qu’une protection infaillible contre les injections de prompt existe.

Le test le plus dérangeant est peut-être le plus simple. Interrogé sur le refresh token OAuth d’un compte Gmail de test, un agent le fournit dans un canal non sécurisé, puis explique aussitôt que c’était risqué et qu’il faudrait révoquer ce token pour en générer un nouveau. Comprendre le risque ne suffit donc pas à l’éviter. Un modèle de langage produit sa réponse au fil de l’eau et ne peut pas reprendre ce qu’il a déjà émis, si bien que sa lucidité arrive après la fuite, sans que rien, entre le modèle et le canal de sortie, ne vienne bloquer l’action.

Au fond, le problème n’est pas que les agents soient imparfaits, mais que les entreprises les déploient comme s’ils ne pouvaient pas l’être, avec de larges accès, des secrets durables et un branchement direct sur des systèmes critiques. Il faut partir du principe inverse et garder en tête qu’un agent ne peut pas divulguer un secret qu’on ne lui a jamais confié, ni abuser d’un accès qu’on ne lui a jamais accordé. Cela suppose d’inventorier les agents déployés, limiter strictement leurs privilèges, bannir les secrets stockés en clair, privilégier des accès éphémères, contrôler les canaux de pilotage, tracer chaque action et pouvoir couper un agent à tout moment. En d’autres termes, il s’agit de gouverner les agents comme des identités à part entière, en leur appliquant ce que l’on a appris, parfois dans la douleur, pour les comptes humains et les comptes de service. Avec une différence de taille : un compte de service n’interprète pas. Un agent, si.