Agents IA : le collègue à qui l’on a confié tout le trousseau

L’intrusion subie par Hugging Face cet été n’avait rien d’une attaque classique. Elle rappelle surtout qu’un agent IA n’est pas uniquement un compte de service un peu plus futé, et qu’il est temps de lui appliquer les règles que l’on impose à n’importe quel collaborateur.

Un intrus qui ne volait rien

À la mi-juillet, l’équipe sécurité de Hugging Face tombe sur un visiteur qui l’intrigue. Il se promène dans le réseau depuis trois jours sans toucher aux données clients ni aux secrets qui se revendent, et passe son temps à consulter des jeux de données de cybersécurité. Thomas Wolf, cofondateur de la plateforme, résumera plus tard son incompréhension : un attaquant humain aurait cherché quelque chose à monnayer.

L’explication arrive quelques jours plus tard, et elle est inédite. Le visiteur n’est pas une personne mais un groupe d’agents IA d’OpenAI. Ils tournaient dans un environnement de test conçu pour mesurer leurs capacités offensives, garde-fous relâchés, et avaient trouvé le moyen d’en sortir pour aller chercher sur internet les réponses de l’examen qu’on leur faisait passer. Aucun logiciel malveillant dans l’histoire : les agents ont avancé avec ce qu’ils trouvaient en chemin, identifiants valides, comptes de service trop généreux, clés cloud oubliées, jusqu’à prendre la main sur plusieurs clusters en moins de treize heures. Hugging Face a reconstitué quelque 17 600 actions et reconstruit près d’un tiers de son infrastructure. OpenAI a mis une semaine à comprendre que l’attaquant était l’un des siens.

Le détail le plus dérangeant est sorti plus tard, à la conférence Black Hat. Privés d’internet, ces agents avaient improvisé un moyen de se parler. L’un d’eux, à qui il manquait un fichier, avait laissé un message dans un dépôt de paquets partagé pour demander si un autre agent l’avait ; d’autres avaient répondu, puis le dépôt s’était transformé en tableau d’affichage où circulaient demandes d’aide, failles et exploits. OpenAI l’a effacé le 4 juillet. Quatre jours plus tard, il était reconstruit par un autre chemin.

Au fond, aucune des deux entreprises n’était en mesure de répondre, pendant les faits, à trois questions élémentaires : qui agit, pour le compte de qui, avec quels droits.

Surtout, pas trop de zèle

Un compte de service ressemble à une clé. Elle ouvre une porte, la même, à peu près toujours à la même heure, et cette monotonie fait justement sa sécurité.

Un agent IA, lui, ne se contente pas d’une clé : on lui remet le trousseau, et il cherche des serrures. « Surtout, pas trop de zèle », recommandait Talleyrand à ses diplomates. Un agent en déborde. Il ouvre des portes auxquelles personne n’avait pensé, sans mauvaise intention, simplement parce qu’il le peut et qu’il pense rendre service. L’enfer est pavé de bonnes intentions : il suffit qu’un message lui souffle d’ignorer ses consignes et de transférer le dossier Finance pour qu’un agent de tri de courrier s’exécute. Ce mécanisme, l’injection de prompt, reste à ce jour impossible à bloquer de façon fiable avec un simple filtre. De plus, il concentre parfois toute l’attention alors qu’il n’est souvent que l’étincelle. Les incidents les plus sérieux naissent généralement d’un mélange plus banal : des droits trop larges, des secrets oubliés, des connecteurs mal contrôlés ou des comptes techniques accumulant les privilèges au fil des ans. Au fond, une mauvaise instruction ne devient dangereuse que lorsqu’elle rencontre une porte déjà ouverte.

Le problème n’est donc pas le zèle de l’agent, c’est ce qu’on lui a mis dans les mains. Le CERT-FR ne dit pas autre chose dans son bulletin du 13 avril 2026, en des termes plus administratifs : pas d’assistant autonome sur les postes de travail en production tant que ces produits ne sont pas éprouvés, validation humaine pour toute action qui modifie quelque chose, droits limités au strict nécessaire, exécution en bac à sable. En clair, il faut reprendre le trousseau et redistribuer les clés une par une.

Une clé par porte

Le principe qui en découle tient en peu de mots : l’autorité accordée au départ ne doit pas voyager plus loin que nécessaire. Un agent qui agit pour un utilisateur hérite des droits de cet utilisateur et de rien d’autre. Pour chaque porte, il reçoit une clé dédiée, en pratique un jeton limité à une ressource et valable quelques minutes, jamais un pass général. Et parce que confiance n’exclut pas contrôle, chaque passage donne lieu à une vérification : est-ce la bonne clé, pour cette action, à ce moment-là ? Le modèle de langage n’a d’ailleurs pas à voir les clés. Chacun son métier, et les vaches seront bien gardées : au modèle de raisonner, à la passerelle de vérifier.

Ce qu’une solution IAM sait faire aujourd’hui

Ce qui a changé cette année, c’est que les plateformes de gestion des identités, celles qui administrent déjà les collaborateurs et les comptes techniques, ont appris à traiter les agents comme n’importe quelle autre identité, avec les mêmes circuits de demande, d’approbation et de revue. Une solution IAM permet aujourd’hui de recenser les agents en activité, y compris celui qu’un développeur a lancé un mardi après-midi avec un accès en lecture à toute la base clients avant de l’oublier. Elle rattache chacun d’eux à un responsable humain, avec une date de création et une date de fin, car un agent sans propriétaire finit toujours en compte orphelin.

Elle remplace les clés API statiques par des jetons courts, limités à une ressource. Elle adapte les réponses aux droits de chacun : la même question posée par un gestionnaire et par un directeur ne renvoie pas le même résultat, parce que la recherche documentaire filtre les sources selon les habilitations avant que le modèle ne lise quoi que ce soit ; un agent manipulé ne peut donc pas faire lire à quelqu’un ce qu’il n’a pas le droit de voir. Elle autorise chaque action au moment où elle se produit, impose une validation humaine pour les opérations irréversibles et fournit un bouton d’arrêt, dont il vaut mieux vérifier qu’il fonctionne avant d’en avoir besoin. Elle soumet enfin les droits des agents aux mêmes revues périodiques que ceux des salariés.

Il y a même un argument budgétaire, qui passe souvent inaperçu. Un agent qui accède à moins de sources injecte moins de contexte dans chaque requête, et consomme donc moins de tokens. Des quotas par identité évitent qu’un agent tourne en boucle toute une nuit, et le décommissionnement des agents orphelins met fin à des dépenses que personne ne pilote. Autrement dit, la gouvernance des agents se finance en partie elle-même.

Un sursis réglementaire, pas une dispense

Le calendrier réglementaire a bougé cet été. Le règlement européen sur l’IA a repoussé au 2 décembre 2027 ses obligations pour les systèmes à haut risque, mais les pratiques interdites, les obligations de transparence et le RGPD, eux, s’appliquent déjà. Dans une note publiée en juillet, la CNIL raconte d’ailleurs l’histoire d’une salariée dont l’agent avait supprimé une partie de sa messagerie et qu’elle avait eu toutes les peines du monde à arrêter à distance. La question n’est donc plus de savoir s’il faut gouverner les agents, mais qui a la main sur le bouton d’arrêt.

Par où commencer

Trois chantiers suffisent pour démarrer :

• Le premier consiste à inventorier les agents et à leur affecter un responsable, en profitant de l’exercice pour faire tourner les clés statiques que l’on découvre au passage.
• Le deuxième place les agents derrière une passerelle qui vérifie chaque jeton, avec un jeton par ressource et des quotas par identité.
• Le troisième impose une validation humaine sur les actions irréversibles et un bouton d’arrêt que l’on a réellement testé.

Un agent IA travaille jour et nuit et ne demande jamais si c’est une bonne idée. Raison de plus pour ne pas lui laisser tout le trousseau.