Moindre privilège pour les agents IA : le rôle est la frontière de permission

« Quels collaborateurs ont le droit d’utiliser des agents IA » est la mauvaise question. Chaque collaborateur en fait déjà tourner un, dans Claude, ChatGPT ou Copilot, et la plupart l’ont branché à quelque chose. La question qui décide si le déploiement survit à un audit est plus étroite : que peut atteindre l’agent, et qui en a décidé.

La réponse inconfortable, dans la plupart des équipes, est que personne n’a décidé. L’agent atteint ce que les outils connectés peuvent atteindre, et les outils ont été connectés avec les identifiants qui se trouvaient sous la main.

Un agent détient l’union des permissions de ses outils

Le contrôle d’accès classique suppose un humain dans la boucle, qui lit un écran et choisit une action. Accordez à cet humain un jeu de permissions, et ce jeu borne ce qui se passe. Ce modèle a été formalisé en 1975 par Saltzer et Schroeder sous le nom de principe du moindre privilège : chaque programme et chaque utilisateur opère avec le plus petit ensemble de privilèges que la tâche exige. Le NIST SP 800-53 le reprend dans le contrôle AC-6, et toute revue de sécurité sérieuse le vérifie.

Un agent casse cette hypothèse d’une façon précise. Il ne choisit pas une action sur un écran. Il lit du texte, venu d’un prompt, d’un document, d’une page web ou du résultat d’un appel d’outil précédent, et décide quoi appeler ensuite. Son jeu de permissions effectif n’est pas la position de l’utilisateur dans l’organigramme. C’est l’union de tous les scopes de tous les connecteurs qu’il voit, exercée par un planificateur qui prend ses instructions dans du texte non fiable.

Connectez le CRM avec un jeton administrateur, la messagerie avec des droits d’envoi complets et le partage de fichiers avec les identifiants de l’utilisateur, et l’agent détient une capacité qu’aucun humain de l’entreprise n’a jamais reçue : lire n’importe quelle fiche client et l’envoyer n’importe où, en un seul tour, sans écran pour marquer une pause.

La défaillance a un nom : excessive agency

L’OWASP la liste sous LLM06:2025 Excessive Agency dans son Top 10 pour les applications LLM. L’entrée la découpe en trois parties qu’il vaut mieux garder séparées, parce que chacune a un propriétaire différent :

• Fonctionnalité excessive : l’agent peut appeler des outils dont la tâche n’a jamais besoin. Un agent de synthèse avec un endpoint de suppression à portée.
• Permissions excessives : les outils nécessaires tournent avec plus de droits que la tâche n’en demande. Un travail en lecture seule fait sur une connexion en lecture-écriture.
• Autonomie excessive : des actions à fort impact s’exécutent sans étape de confirmation humaine.

Simon Willison a donné un nom à la forme de l’attaque en juin 2025 : la lethal trifecta. Un agent qui peut lire des données privées, est exposé à du contenu non fiable et peut communiquer vers l’extérieur est exploitable par construction. Retirez l’un des trois pieds et l’attaque s’effondre. Le moindre privilège est la discipline qui consiste à retirer des pieds volontairement, tâche par tâche, au lieu d’espérer que le prompt tienne.

MCP a déplacé le problème, il ne l’a pas supprimé

Le Model Context Protocol (MCP) a rendu les outils portables. Un serveur, n’importe quel client. C’est la bonne nouvelle. La page de bonnes pratiques de sécurité de la spécification est franche sur ce que coûte cette portabilité :

• Confused deputy. Un serveur MCP qui relaie une API tierce pour le compte de nombreux utilisateurs peut être amené à agir avec l’autorisation d’un utilisateur pour le compte d’un autre. Le serveur détient l’autorité ; l’agent fournit l’intention ; l’intention vient du texte.
• Token passthrough. Un serveur qui accepte un jeton émis pour un autre service et le transmet en amont contourne tous les contrôles que ce service aurait appliqués. La spécification l’interdit. Beaucoup d’intégrations rapides le font quand même, parce que ça marche du premier coup.

La section sur les outils ajoute la ligne qui compte le plus pour quiconque branche des agents à des systèmes de production : les descriptions d’outils viennent du serveur et ne sont pas fiables tant que le serveur ne l’est pas. Une description d’outil est une entrée du modèle. Qui contrôle la description contrôle une partie du plan. C’est le même problème de contenu que celui décrit dans la composition de MCP et des skills, lu du côté sécurité : chaque connecteur déversé dans le contexte est une surface de plus sur laquelle un attaquant peut écrire.

Les permissions par utilisateur ne bornent pas un agent

Le réflexe est de réutiliser la pile d’identité. Authentification unique, appartenance à des groupes, un jeton personnel par collaborateur. Cela ressemble au moindre privilège parce que c’est le moindre privilège, pour un humain.

Pour un agent, cela échoue sur trois points.

Le scope est la personne, pas la tâche. L’identité d’un analyste financier peut lire le grand livre et passer des écritures. Un agent qui rédige un commentaire d’écarts a besoin du premier et ne doit jamais avoir le second. Des identifiants personnels ne peuvent pas exprimer cette séparation sans créer une seconde identité par tâche, que personne ne maintient.

Le droit s’élargit à l’exécution. Les agents découvrent des outils. Un client qui liste tous les serveurs que l’utilisateur a un jour autorisés remet au planificateur tous les scopes d’un coup, que la tâche en ait besoin ou non. Le context bloat qui dégrade la précision est la même liste qui dégrade la sécurité.

Personne ne peut répondre à « pourquoi a-t-il fait cela ». Quand le jeton est personnel, la trace d’audit dit que la personne l’a fait. La personne ne l’a pas fait. Une injection dans un PDF fournisseur l’a fait, et le journal ne sait pas faire la différence. C’est cet écart qui transforme le shadow AI d’un souci de fuite de données en un problème de responsabilité, et c’est pourquoi un SKILL.md communautaire que personne n’a relu expose plus qu’il n’y paraît.

Le rôle est la frontière de permission

L’unité qui convient à un agent n’est ni l’utilisateur ni l’outil. C’est le rôle : le travail qu’un poste de l’organigramme fait réellement, exprimé comme un ensemble de skills (les instructions) et d’outils scopés (les connecteurs), avec les permissions rattachées à l’ensemble plutôt qu’à la personne qui l’invoque. Un rôle se configure depuis un blueprint sur les processus propres à une équipe ; ce n’est jamais un paquet prêt à l’emploi.

Quatre propriétés font d’un rôle une vraie frontière plutôt qu’une convention de nommage. L’équipe skilder a depuis testé ce design contre l’injection d’outils à plat et l’orchestration multi-agents sur 13 scénarios et six modèles ; ce que mesure le papier est la moitié enforcement de cet argument.

Accordé centralement, et il ne s’élargit pas à l’exécution. Une personne qui en a l’autorité décide quels serveurs le rôle peut atteindre et avec quels scopes. L’agent qui tient le rôle voit ces outils et aucun autre. La découverte se fait à l’intérieur de la frontière, jamais au travers.

Scopé par tâche, pas par personne. Le rôle de commentaire d’écarts reçoit la lecture du grand livre. Un rôle distinct de clôture reçoit l’écriture des journaux, avec une étape de confirmation à chaque passage. Deux rôles, deux octrois, une personne autorisée à invoquer les deux. La pile d’identité authentifie toujours la personne ; elle ne définit plus la portée.

Adossé à un registre curé, pas à un annuaire ouvert. Les serveurs qu’un rôle peut nommer viennent d’une liste interne de connecteurs relus, dotés d’identifiants et scopés une fois pour toutes. Ajouter un serveur à cette liste est l’étape d’autorisation. Un rôle ne peut pas atteindre un serveur qui n’y figure pas, ce qui ferme le raccourci du token passthrough par construction.

Chaque appel rattaché à une personne, à travers le rôle. Le journal enregistre qui a invoqué le rôle, quel outil l’agent a appelé, avec quels arguments, et ce qui est revenu. Quand un résultat d’outil portait une instruction injectée, la trace montre le tour où le plan a changé. C’est la différence entre un rapport d’incident et une supposition.

C’est ainsi que skilder est construit : les rôles regroupent des skills et des outils MCP scopés, sont accordés par un contrôle d’accès basé sur les rôles, et sont servis à la demande à l’agent que le collaborateur utilise déjà. La trace d’exécution est conservée, attribuable et exportable, comme décrit sur la page confiance et sécurité.

Une checklist pour le prochain connecteur que vous branchez

Le moindre privilège pour les agents est une habitude, pas un produit. L’habitude ressemble à ceci.

1. Nommez le rôle avant l’outil. Écrivez une phrase qui décrit le travail. Si la phrase exige deux permissions d’écriture différentes, ce sont deux rôles.
2. Accordez la lecture avant l’écriture, et l’écriture avec confirmation. Tout outil qui modifie un état hors de la conversation reçoit une étape humaine tant que le rôle n’a pas fait ses preuves.
3. Ne passez jamais un jeton personnel à un serveur. Le serveur reçoit son propre identifiant, scopé sur ce dont le rôle a besoin. Si l’API en amont ne sait pas scoper aussi finement, le serveur l’enveloppe et n’expose que les opérations étroites.
4. Traitez les descriptions et les résultats d’outils comme des entrées. Relisez les descriptions d’un serveur avant son entrée au registre. Journalisez les résultats. Partez du principe qu’un document peut parler au planificateur, parce qu’il le peut.
5. Cassez la trifecta volontairement. Pour un rôle qui lit des données privées et ingère du contenu non fiable, retirez le canal externe. Pour un rôle qui doit envoyer vers l’extérieur, tenez-le à l’écart de la lecture sensible. Un des trois pieds saute, à chaque fois.
6. Journalisez vers la personne, à travers le rôle. Si la trace ne sait pas dire qui a invoqué quel rôle et ce que l’agent a appelé, le déploiement n’est pas prêt pour des données de production.

Les équipes qui réussissent cela ne livrent pas plus lentement. Elles livrent le premier rôle lentement et tous les suivants vite, parce que l’octroi est fait une fois et réutilisé, au lieu d’être renégocié par personne et par outil.

À retenir : cessez de demander qui peut utiliser l’agent, et demandez ce que chaque rôle peut atteindre. Puis rendez cet octroi central, scopé, et impossible à élargir depuis un prompt.

Pour voir comment les rôles, les outils scopés et la trace d’exécution s’articulent, commencez par la documentation skilder.

Questions fréquentes

Que signifie le moindre privilège pour un agent IA ? +

L'agent ne peut atteindre que les outils, les données et les actions dont la tâche en cours a besoin, et rien d'autre. Concrètement : scoper les connecteurs par rôle plutôt que par utilisateur, accorder la lecture avant l'écriture, et refuser tout droit que l'agent pourrait élargir seul pendant une exécution.

Pourquoi un jeton d'API personnel est-il la mauvaise façon de connecter un agent ? +

Un jeton personnel porte toutes les permissions de la personne sur tous les systèmes qu'il touche. L'agent raisonne ensuite sur l'ensemble. Une instruction injectée dans un document ou un résultat d'outil suffit à transformer cette portée en une action que personne n'a demandée. La spécification MCP appelle cela le problème du confused deputy et proscrit le token passthrough pour la même raison.

Le moindre privilège ralentit-il l'adoption des agents ? +

Il ralentit la première connexion et accélère toutes les suivantes. Une fois qu'un rôle existe avec ses outils scopés, l'équipe suivante le réutilise au lieu de négocier un nouveau jeu d'identifiants. Le coût passe de chaque utilisateur à un seul octroi central.