En clair
Dans un immeuble de bureaux, on peut afficher sur la porte de la salle des archives : « Merci de ne pas entrer sans autorisation ». C’est une consigne : la plupart des gens la respectent, mais rien n’empêche physiquement quelqu’un de passer. On peut aussi programmer les badges pour que la porte refuse de s’ouvrir. La politique IAM, pour « gestion des identités et des accès », c’est le badge, pas l’affiche.
Un agent IA qui agit dans les systèmes de l’entreprise utilise une identité, comme un salarié utilise son badge. On peut lui écrire dans ses instructions « ne supprime jamais de données ». Mais un modèle peut se tromper, mal comprendre ou être manipulé par un texte piégé. La politique IAM, elle, est appliquée par le système visé, en dehors du modèle : si l’action est interdite, la requête est rejetée, que l’agent l’ait voulu ou non.
Ces politiques combinent deux types de règles. Les autorisations ouvrent des droits ; les interdictions, appelées règles de refus ou « deny », les ferment. Le principe clé est simple : une interdiction explicite gagne toujours. On peut ainsi accorder des droits larges pour travailler confortablement, puis verrouiller les quelques actions dangereuses par une règle de refus que rien ne pourra contourner.
Un exemple
Une entreprise de distribution veut laisser un agent de programmation interroger son entrepôt de données pour produire des analyses de ventes. L’équipe a ajouté à l’agent une compétence qui lui demande de solliciter l’accord explicite d’un humain avant toute suppression de table. Le responsable de la sécurité juge que ce n’est pas suffisant : une consigne peut être ignorée.
Il crée donc pour l’agent une identité dédiée et lui attache une règle de refus : tout outil qui ne se contente pas de lire des données est bloqué. Quelques semaines plus tard, l’agent tente, à la suite d’une instruction ambiguë, de vider une table de test. La requête est rejetée par la plateforme, l’incident est consigné et aucune donnée n’est perdue. Les opérations d’écriture restent possibles, mais sous une autre identité, réservée aux humains.
Comment ça marche
Les grands fournisseurs d’informatique en nuage reposent tous sur ce mécanisme. Chez Amazon Web Services, toute requête est refusée par défaut, sauf pour l’utilisateur racine du compte, et doit être explicitement autorisée par une politique ; un refus explicite l’emporte sur une autorisation explicite 1. Google Cloud propose des politiques de refus qui empêchent certaines identités d’utiliser certaines permissions, quels que soient les rôles qui leur ont été accordés, parce que le service vérifie toujours les refus avant les autorisations 2.
- IdentifierDonner à l’agent sa propre identité, distincte de celles des humains, pour que ses droits puissent être réglés séparément.
- AutoriserAccorder à cette identité les seules permissions nécessaires à sa mission, selon le principe du moindre privilège.
- InterdireAjouter des règles de refus, éventuellement conditionnelles, pour les actions dangereuses comme l’écriture ou la suppression.
- ÉvaluerÀ chaque requête, le service vérifie d’abord les refus, puis les autorisations ; sans autorisation, la requête est rejetée.
- TesterVérifier que les actions interdites échouent réellement, en simulant les erreurs ou détournements possibles de l’agent.
Ordre d’évaluation décrit d’après les documentations d’Amazon Web Services et de Google Cloud ; les détails varient selon les fournisseurs.
Une règle de refus de Google Cloud désigne les identités visées, les permissions interdites et, en option, une condition. Elle s’attache à un projet, à un dossier ou à l’organisation entière, et vaut pour toutes les ressources qui en dépendent ; chaque ressource peut porter jusqu’à 500 politiques de refus, totalisant 500 règles au plus 2. Détail important pour la sûreté : si la condition ne peut pas être évaluée, le refus s’applique 2. Pour les serveurs MCP gérés par Google, un appel d’outil exige à la fois la permission d’appeler les outils sur le projet et les droits sur la ressource sous-jacente ; les règles de refus peuvent cibler le service, le nom de l’outil, l’application cliente, ou le fait qu’un outil se limite à lire des données (attribut tool.isReadOnly) 3.
Il faut distinguer ce mécanisme des annotations du protocole MCP. Depuis la révision du 26 mars 2025, un serveur peut signaler qu’un outil est en lecture seule, destructif, idempotent ou ouvert sur l’extérieur, mais ce ne sont que des indications : un serveur non fiable peut se déclarer en lecture seule et effacer quand même des fichiers 4. La politique IAM est appliquée par le système qui détient la ressource. Le cas du Data Agent Kit de Google, sorti en octobre 2026, illustre cette frontière : une compétence demande à l’agent de s’arrêter avant une opération destructrice, tandis qu’une politique de refus bloque l’appel lui-même 5. Le mécanisme a ses limites : un outil bloqué reste visible dans la liste des outils, le contrôle ne couvre que les serveurs MCP de Google, et certains attributs ne se règlent qu’en ligne de commande 35.
Ce que ça change pour une entreprise
Dès qu’un agent peut agir sur des données réelles, la question n’est plus « que lui a-t-on demandé ? » mais « que peut-il techniquement faire ? ». La politique IAM y répond de façon vérifiable et auditable, avec des outils que les équipes de sécurité maîtrisent déjà. Une règle de refus bien placée permet de laisser un agent explorer librement en lecture tout en rendant impossibles les opérations irréversibles. Le coût est surtout humain : définir une identité par agent, rédiger les règles, souvent sous forme de code puisque certains réglages ne sont pas accessibles depuis la console 5, puis les maintenir.
Les limites sont réelles. Une règle de refus n’empêche pas un agent autorisé à lire de divulguer ce qu’il lit : elle protège contre la destruction, pas contre la fuite. Elle ne couvre que les systèmes qui l’appliquent ; chez Google, les serveurs MCP tiers échappent à ce contrôle 3. Une règle trop large, placée au niveau de l’organisation, peut bloquer des processus légitimes. Enfin, le mécanisme repose sur la justesse des attributs évalués : une étiquette « lecture seule » ne vaut que si elle provient d’un serveur de confiance 4.
Idées reçues
- « Si l’agent a reçu la consigne de ne rien supprimer, il ne supprimera rien. »
Une consigne reste consultative : le modèle peut se tromper ou être manipulé par un contenu piégé. Seule une règle appliquée par le système visé bloque réellement l’action.
- « Un outil déclaré en lecture seule ne peut rien modifier. »
Dans le protocole MCP, cette déclaration est une simple indication fournie par le serveur, qu’un serveur non fiable peut falsifier. Elle ne vaut que si la source est digne de confiance.
- « Une règle de refus sur l’écriture suffit à sécuriser un agent. »
Elle empêche les modifications, pas la divulgation de ce que l’agent a le droit de lire. Elle ne couvre que les systèmes qui l’appliquent et se combine avec d’autres protections.
Sources
- Amazon Web Services, « How AWS enforcement code logic evaluates requests to allow or deny access », documentation IAM
- Google Cloud, « Deny policies », documentation IAM
- Google Cloud, « Control MCP use with Identity and Access Management », documentation des serveurs MCP
- Model Context Protocol, « Tool Annotations as Risk Vocabulary: What Hints Can and Can’t Do », 2026
- InfoQ, « Google’s Data Agent Kit Hits GA, Splitting Agent Guardrails Between Skills and IAM », 2026