En clair
Dans un immeuble de bureaux, un stagiaire reçoit un badge qui ouvre l’accueil, son étage et la salle de réunion, mais pas la salle des serveurs. On peut aussi lui dire : « N’entre jamais dans la salle des serveurs. » Ce sont deux protections très différentes. La consigne compte sur sa bonne volonté et sa mémoire. Le badge, lui, ne laisse tout simplement pas passer. Les permissions IAM sont le badge.
Un agent d’IA agit par l’intermédiaire d’outils : lire une table, envoyer un courriel, supprimer un fichier. On peut écrire dans ses instructions « demande toujours avant de supprimer quoi que ce soit ». C’est utile, mais c’est une consigne : le modèle peut se tromper, mal comprendre la demande ou être manipulé par un texte piégé glissé dans un document. La permission, elle, est vérifiée en dehors du modèle, par le système qui reçoit l’appel. Si l’action n’est pas permise, elle échoue, quel que soit le raisonnement de l’agent.
Deux règles simples organisent l’ensemble. Par défaut, rien n’est permis : chaque droit doit être accordé explicitement. Et une interdiction explicite l’emporte toujours sur une autorisation. On peut donc poser au sommet de l’organisation une interdiction large, par exemple « aucun agent ne modifie de données », que personne ne pourra contourner plus bas en accordant un droit par inadvertance.
Un exemple
L’équipe données d’une enseigne de distribution utilise un agent de programmation relié à son entrepôt de données dans le nuage pour analyser les ventes. Les instructions de l’agent lui demandent de solliciter l’accord de l’utilisateur avant toute suppression. L’équipe sécurité ajoute deux protections : l’agent fonctionne sous un compte dédié qui n’a que des droits de lecture sur les tables de ventes, et une règle d’interdiction, posée au niveau de l’organisation, refuse tout outil qui n’est pas déclaré en lecture seule.
Un jour, un analyste demande à l’agent de « faire le ménage » dans les tables de test. L’agent tente une suppression : l’appel est refusé et renvoie une erreur, l’agent le signale, et l’analyste passe par la procédure habituelle. L’équipe remarque que l’agent voit toujours les outils d’écriture dans sa liste et perd des étapes à les essayer. Elle précise donc dans ses instructions qu’il travaille en lecture seule, et fait relire chaque mois le journal des refus.
Comment ça marche
Les principes remontent à l’article de Jerome Saltzer et Michael Schroeder publié en 1975 1. Le moindre privilège veut que chaque programme et chaque utilisateur fonctionne avec le plus petit ensemble de droits nécessaire à sa tâche, ce qui limite les dégâts d’un accident ou d’une erreur. Le refus par défaut veut que l’accès repose sur une permission plutôt que sur une exclusion : une erreur dans un mécanisme qui accorde des droits explicites se traduit par un refus, vite repéré. Les systèmes IAM des grands fournisseurs de nuage appliquent ces règles. Chez AWS, toute requête est implicitement refusée tant qu’une politique ne l’autorise pas, et une interdiction explicite l’emporte sur une autorisation explicite 2.
- IdentifierAttribuer à l’agent une identité propre, par exemple un compte de service, distincte de celle des salariés.
- AutoriserAccorder à cette identité les seuls droits nécessaires à sa tâche, et rien d’autre.
- InterdirePoser des règles de refus explicites, au niveau de l’organisation, sur les actions jugées dangereuses.
- ContrôlerÀ chaque appel d’outil, le système vérifie les règles : refus par défaut, et l’interdiction l’emporte toujours.
Appliquées aux agents, ces règles portent sur les appels d’outils. Google Cloud permet ainsi de poser des politiques d’autorisation et d’interdiction sur ses serveurs MCP, avec des conditions sur le service, le nom de l’outil, l’identifiant du client OAuth ou le caractère « lecture seule » de l’outil 3. Une politique d’interdiction fondée sur l’attribut tool.isReadOnly fait échouer, avec une erreur HTTP, tout appel à un outil qui n’est pas annoté en lecture seule 3. Elle retire la permission mcp.googleapis.com/tools.call et s’applique à l’organisation, à un dossier ou à un projet 5. Dans le Data Agent Kit de Google, passé en disponibilité générale à l’automne 2026, elle coexiste avec une skill anti-perte de données qui demande à l’agent d’obtenir l’accord explicite de l’utilisateur avant une opération irréversible : l’une est une consigne que l’agent est prié de suivre, l’autre refuse l’appel 5.
Le mécanisme a ses limites. Un outil bloqué reste visible dans la liste renvoyée par tools/list : l’agent ne découvre le refus qu’au moment de l’appel 5. Ces politiques ne couvrent que les serveurs MCP de Google Cloud, pas ceux de tiers 3. L’OWASP classe le risque correspondant sous le nom d’« agentivité excessive », avec trois causes : trop de fonctions, trop de permissions, trop d’autonomie ; il recommande de réduire les outils offerts et leurs droits, en faisant respecter ces limites dans le système cible, par exemple par les droits de l’identité utilisée pour se connecter à la base de données 4. Les permissions se distinguent des garde-fous, qui filtrent les entrées et sorties du modèle, et de la politique IAM, qui est le document où ces règles sont écrites.
Ce que ça change pour une entreprise
Les permissions IAM permettent de confier des tâches à un agent sans s’en remettre à son jugement pour les actions irréversibles. Le risque se pilote comme pour un salarié : une identité dédiée, des droits minimaux, des interdictions centrales que les équipes ne peuvent pas lever seules. Les mécanismes sont déjà inclus dans les grandes plateformes de nuage. Le coût est surtout humain : recenser les outils accessibles à chaque agent, définir ses rôles, maintenir les règles et relire les journaux de refus.
La protection ne vaut que pour ce qui passe par le système qui applique les règles : un outil hébergé ailleurs ou un script local y échappe 3. Un droit de lecture n’empêche pas non plus qu’une donnée lue soit divulguée si l’agent est manipulé. Le piège le plus courant est de brancher l’agent sur un compte partagé à privilèges élevés, que l’OWASP cite parmi les exemples de permissions excessives 4. À l’inverse, des règles trop strictes rendent l’agent inutile : il bute sur des refus qu’il ne voit qu’au moment d’agir 5.
Idées reçues
- « Il suffit d’écrire dans les instructions de l’agent qu’il ne doit rien supprimer. »
Une instruction est une consigne que le modèle peut ignorer, par erreur ou sous l’effet d’une manipulation. Seul un contrôle extérieur au modèle bloque réellement l’action.
- « Si l’agent agit avec mes propres droits, il ne peut rien faire de grave. »
Il peut alors faire tout ce que vous pouvez faire, y compris supprimer. Mieux vaut une identité dédiée aux droits réduits à sa tâche.
- « Un outil interdit disparaît de la vue de l’agent. »
Pas forcément : sur les serveurs MCP de Google Cloud, un outil bloqué reste dans la liste des outils, et le refus n’intervient qu’au moment de l’appel.
Sources
- Saltzer et Schroeder, « The Protection of Information in Computer Systems », 1975
- Amazon Web Services, « How AWS enforcement code logic evaluates requests to allow or deny access », documentation IAM
- Google Cloud, « Control MCP use with Identity and Access Management », documentation
- OWASP, « LLM06:2025 Excessive Agency », 2025
- InfoQ, « Google’s Data Agent Kit Hits GA, Splitting Agent Guardrails Between Skills and IAM », 2026