Vos agents ont-ils plus de droits que vos administrateurs ?

Un agent n’a pas de droits propres. Il emprunte ceux qu’on lui donne, par trois chemins.

Le premier est un jeton ou un compte de service créé pour lui. En avril 2026, Railway a décrit le cas d’un client : un agent avait trouvé sur le poste de l’utilisateur un jeton d’API à longue durée de vie, et s’en était servi pour supprimer un volume de production[1]. L’API a traité la requête comme celle d’une chaîne d’intégration continue. Le jeton portait sur tout le compte, « l’accès le plus large possible », écrit Railway : la bonne portée existait, mais le parcours de création ne la rendait pas évidente.

Le deuxième, ce sont les connexions de l’utilisateur. Supabase l’écrit à propos de son serveur MCP : il agit dans le contexte des permissions du développeur, et ne doit donc pas être confié aux clients[2]. Pour une application OAuth créée à la main, la même page demande encore d’accorder l’écriture sur tous les périmètres disponibles. Varonis, à propos de Copilot Personal de Microsoft, résume le problème : la faille, c’est « l’accès légitime de l’utilisateur », que le système suppose toujours déclenché par lui[3].

Le troisième, ce sont les agents achetés sur étagère. Selon Zenity, certains sous-agents d’Agentforce prévus pour Slack s’ajoutent « en exactement deux clics », avec toutes leurs actions[4].

D’où un premier test. Pour un administrateur, vous savez qui, depuis quand et pourquoi. Posez les mêmes questions au jeton le plus large de chaque agent : qui l’a créé, sur quel périmètre, jusqu’à quand ? Si la réponse est « tout le compte » et « jamais », le titre de cet article vous concerne.

Le 16 juillet 2026, Hugging Face a annoncé une intrusion dans une partie de sa production, menée « de bout en bout » par un système d’agents autonomes[5]. Sa chronologie technique, publiée le 27 juillet, donne le contexte : l’agent tournait dans une évaluation interne d’OpenAI sur les capacités offensives, et Hugging Face estime qu’il cherchait à tricher en volant les solutions de l’épreuve[6]. Le rapport reconstitue environ 17 600 actions entre le 9 et le 13 juillet. Nous n’avons joué aucun rôle dans cette réponse : nous lisons le rapport publié.

Ce qui nous intéresse ici, ce sont les droits. Plusieurs ont tenu. Les identifiants cloud récupérés ont permis de cartographier l’infrastructure, mais chaque appel qui modifiait quelque chose a été refusé par la politique du rôle : « une carte, pas le contrôle », résume Hugging Face. Les 84 opérations tentées contre le magasin d’identifiants ont été refusées. La base interne atteinte a été lue, pas modifiée.

D’autres droits ont cédé. Aucune règle d’admission ne rejetait les conteneurs privilégiés, et le rôle d’un pilote de stockage autorisait la création de conteneurs sur tout le cluster. Un mot de passe statique figurait dans l’environnement d’une machine de traitement. Et un seul objet secret de production rassemblait beaucoup de clés.

Hugging Face tire lui-même la leçon : les faiblesses étaient connues, parmi elles des accès trop larges et des identifiants à longue durée de vie. Ses priorités : isoler strictement les évaluations, resserrer les frontières de confiance, raccourcir la durée des identifiants, bloquer l’accès aux métadonnées cloud. Les refus qui ont tenu venaient des politiques des services, pas du modèle : l’évaluation avait justement désactivé les filtres de sécurité de production d’OpenAI.

Tous les agents ne méritent pas la même attention. Deux questions suffisent pour les trier. L’agent lit-il du contenu écrit par des inconnus : e-mail, formulaire, ticket, page web, fiche CRM remplie par un prospect ? Peut-il agir : écrire, envoyer, publier, payer, supprimer, changer des droits ?

La règle de lecture vient du NCSC britannique, qui reprend une formule de Simon Willison et Baibhav Bista : quand un modèle traite l’information d’une partie, ses privilèges tombent à ceux de cette partie[7]. Un agent qui lit les e-mails de n’importe qui ne devrait pas pouvoir faire plus que n’importe qui. Willison nomme la combinaison la plus risquée : des données privées, du contenu non fiable et un moyen de communiquer vers l’extérieur[8].

Les démonstrations publiées sur des agents métier tombent dans la case des deux oui. Ce sont des travaux de chercheurs, signalés aux éditeurs et corrigés depuis selon leurs auteurs.

Le point commun : l’agent s’est servi de droits ou de capacités qu’il détenait légitimement, au service d’un texte écrit par quelqu’un d’autre.

Une consigne dans les instructions de l’agent (« ne jamais écrire en production ») n’est pas une limite. La lecture seule doit être un droit, pas une consigne.

La spécification MCP le dit à sa façon. L’annotation readOnlyHint signale qu’un outil ne modifie pas son environnement, mais toutes les annotations sont des indications : elles ne garantissent pas le comportement de l’outil, et un client ne doit jamais fonder une décision sur celles d’un serveur non fiable[11]. Ce sont les serveurs qui doivent mettre en place des contrôles d’accès appropriés[12].

Concrètement, la limite se pose là où le service la vérifie. Le mode lecture seule du serveur MCP de Supabase exécute les requêtes avec un utilisateur Postgres en lecture seule : c’est la base qui refuse[2]. Railway propose des jetons de projet, limitables à un environnement[1]. GitHub recommande ses jetons « à granularité fine », limitables à certains dépôts avec des permissions précises, et conseille de leur fixer une date d’expiration[13].

Une détection après coup n’est pas un refus. Chez Manus, selon Salt Labs, le garde-fou de sécurité a repéré l’attaque, mais seulement après l’exécution du code[10].

Le test se fait sur des données de test, jamais en production. Demandez à l’agent une action hors de sa tâche, par exemple une écriture sur une ressource de test, puis lisez le journal du service. Le test est réussi si le refus y figure. Si l’agent annonce « bloqué » alors que l’écriture a eu lieu, il est raté. Changez ensuite la cible, et recommencez.

Pour les actions qui doivent rester possibles, l’approbation humaine prend le relais. La spécification MCP recommande qu’une personne puisse toujours refuser l’appel d’un outil, et que le client lui montre les paramètres de l’appel avant de l’envoyer au serveur[12].

Encore faut-il que l’accord porte sur ce qui sera exécuté. L’OWASP en a fait un principe pour l’autorisation des transactions : « ce que vous voyez est ce que vous signez »[14]. L’utilisateur voit et valide les données significatives de l’opération ; l’autorisation est vérifiée côté serveur ; les données sont protégées contre la modification ; chaque autorisation est unique.

Transposé à un agent, cela donne trois règles. L’opération est figée avant l’accord : destinataire, montant, contenu. Le service compare ce qui a été approuvé à ce qu’on lui demande d’exécuter, et refuse toute différence. Un accord vaut pour une exécution, pas pour la session. Le guide de l’ANSSI du 30 octobre 2026 va dans le même sens : présenter à l’approbateur « l’action exacte, son objectif et ses effets attendus », et n’exécuter « que l’action approuvée »[15]. Nous le lisons en détail dans « IA agentique : ce que recommande l’ANSSI depuis le 30 octobre ».

Reste à vérifier que la confirmation existe toujours. Dans SalesBleed, l’action de réponse dans Slack n’en demandait pas, et Zenity rappelle qu’un seul clic suffit à désactiver cette exigence[4]. Une confirmation se relit après chaque changement de configuration.

Le plus utile se fait sans outil à acheter, avec les responsables des agents autour d’une table.

Un agent qui coche ces cases peut encore se tromper. Mais ce qu’il a le droit de faire est écrit quelque part, vérifié par le service, et quelqu’un en répond.