Accorder des autorisations à un agent d'intelligence artificielle n'est pas une simple tâche de configuration : c'est une décision risquée qui doit être prise avec la même rigueur que celle consistant à déterminer qui est habilité à signer sur un compte bancaire. Chaque autorisation supplémentaire accroît le potentiel de dommage, et cette augmentation n'est pas compensée par la qualité du modèle, car le risque ne provient pas d'un défaut intrinsèque du modèle : il provient du fait qu'il peut être manipulé ou commettre des erreurs dans le cadre des autorisations qui lui ont été accordées.
La formulation que nous utilisons en interne est simple : Un agent ne peut causer de préjudice dans un lieu où il n'est pas autorisé à agir.. L'ensemble de la conception de la sécurité d'un système multi-agents découle de cette phrase.
Dans son rapport 2025 sur les 10 principaux risques liés aux applications de modèles de langage, l'OWASP classe l'injection de prompts en tête pour la deuxième année consécutive et lui consacre une catégorie entière – LLM06, *Agence excessive* – précisément. Elle la décompose en trois formes :
Ces trois décisions relèvent de choix de conception, et non de défauts de modélisation. Elles sont presque toujours prises lors de la phase d'intégration, pour des raisons techniques et à l'insu de tous les membres de l'entreprise.
Le lien entre ces deux approches réside dans l'injection indirecte d'instructions : un contenu externe (un courriel, un PDF provenant d'un fournisseur, une page web, un ticket client) contenant des instructions destinées au modèle. L'agent interprète ce contenu comme faisant partie de son contexte et agit en conséquence. Si ses autorisations sont étendues, un texte rédigé par un tiers peut ainsi exécuter des actions au sein de vos systèmes.
C’est pourquoi la sécurité d’un agent ne se résout pas en choisissant un meilleur modèle, mais en limitant ses actions lorsqu’une personne parvient à l’influencer.
Voici un changement structurel que de nombreuses organisations n'ont pas encore intégré à leur gestion des accès. Pendant vingt ans, le contrôle des identités a été conçu pour les personnes : intégration, départ, rôles, évaluations périodiques. Or, les agents créent des identités qui ne correspondent pas à des personnes ; elles sont créées en quelques minutes, n'apparaissent pas dans l'organigramme et sont rarement vérifiées.
Le rapport d'IBM sur le coût d'une violation de données en 2025 fournit les données qui étayent l'argument : Parmi les 971 organisations ayant subi un incident lié à l'IA, 971 présentaient des contrôles d'accès inadéquats.. Ce n'est pas un problème de sophistication de l'attaquant, mais un problème de gestion des autorisations.
Nous l'avons traité en détail dans identités non humaines, agents d'IA et cybersécurité, En résumé, voici ce qu'il en est : si votre processus de gestion des accès n'inclut pas les identités non humaines, votre inventaire des accès est incomplet, et probablement là où il y a le plus d'impact.
Tous les permis ne présentent pas le même profil de risque. Cette classification permet de prendre une décision en trente minutes.
Niveau | Que peut faire l'agent ? | Contrôle requis |
1. Lecture limitée | Interroger les données d'un domaine spécifique | Journalisation des accès et limite de volume |
2. Lecture approfondie | Consulter plusieurs systèmes et des données sensibles | Autorisations basées sur les rôles, masquage des données, audit |
3. Écriture réversible | Créer des brouillons, des propositions, des dossiers en attente | Validation humaine avant confirmation |
4. Écriture irréversible | Paiements, communications avec les clients, changements de production | Approbation explicite, double contrôle et plan de réversion |
En règle générale, L'essentiel de la valeur commerciale se situe aux niveaux 1 et 3., et la majeure partie du risque se situe à l'étape 4. Un agent qui prépare le remboursement et le laisse en attente d'approbation capte la quasi-totalité des gains de temps avec une fraction du risque de celui qui exécute le remboursement.
Quand quelqu'un insiste sur le niveau 4, la question pertinente est : quelle est la valeur ajoutée par rapport au niveau 3 ? Généralement, il s'agit du temps nécessaire pour appuyer sur un bouton. Et ce temps est rarement compensé.
L'identité de soi par l'agent. Nul besoin d'utiliser un compte partagé ni de réutiliser un compte de service existant. Sans identité unique, il est impossible de déterminer ce qui s'est passé.
Indemnité minimale par tâche, et non par agent. Si l'agent effectue trois tâches différentes, chacune doit avoir son propre périmètre d'application. Une autorisation accordée pour une tâche est valable pour toutes les autres.
Qualifications à court terme. Des jetons qui expirent, et non des clés permanentes dans un fichier de configuration.
Liste blanche des actions. Il convient de définir explicitement les opérations autorisées plutôt que celles qui ne le sont pas. Cette dernière approche est toujours incomplète.
Limites de volume et de quantité. Un agent habilité à effectuer des remboursements doit se voir appliquer une limite par transaction et par jour. Ce principe s'applique à tout particulier disposant d'un pouvoir d'achat.
Enregistrement complet et immuable. Qu'est-ce qui a été saisi, qu'est-ce qui a été décidé, qu'est-ce qui a été exécuté, avec quelle version du modèle et qui l'a validé ? Sans ces informations, il n'y a ni audit ni défense possible.
Interrupteur d'arrêt. Un mécanisme permettant d'arrêter l'agent sans déployer de code et sans dépendre du fournisseur.
Aucune de ces sept pratiques n'est inhabituelle. Ce sont toutes des mesures de sécurité standard appliquées à un nouvel acteur. Ce qui est frappant, c'est la fréquence à laquelle elles sont omises précisément parce que l'acteur est nouveau et ne correspond pas aux procédures existantes.
Le risque de cet article est qu'il soit perçu comme un plaidoyer pour l'inaction. Ce n'est pas le cas. L'approche qui fonctionne est la mise à l'échelle progressive.
Il s’agit du même principe de supervision à plusieurs niveaux que nous appliquons lors de l’intégration de composants d’IA dans les systèmes d’entreprise, et c’est pourquoi la gouvernance n’est pas une phase finale du projet mais une propriété de son architecture, comme nous l’avons expliqué dans Risques, hallucinations et gouvernance de l'IA
Avant d'approuver le déploiement d'un agent, il est conseillé de répondre à la question suivante : Si un inconnu pouvait écrire le texte que cet agent s'apprête à lire, quelle serait la pire chose qu'il pourrait lui faire faire ?
Si la réponse est « consulter les informations publiques », le risque est acceptable. Si la réponse est « effectuer un paiement » ou « écrire à tous nos clients », la conception est incomplète.
Car ils déterminent la surface potentiellement endommagée. Un agent ne peut causer de dommages là où il n'est pas autorisé, quelle que soit la qualité du modèle ou même s'il a été manipulé. L'OWASP consacre une catégorie distincte à ce problème dans son classement des 10 principales applications de master en droit (LLM) pour 2025 : « Excessive Agency ».
Il s'agit de l'octroi de capacités excessives à un agent, sous trois formes : fonctionnalités excessives (accès à des outils que sa tâche ne requiert pas), permissions excessives (identité assortie de plus de privilèges que nécessaire) et autonomie excessive (exécution d'actions à fort impact sans validation humaine).
Il s'agit de l'octroi de capacités excessives à un agent, sous trois formes : fonctionnalités excessives (accès à des outils que sa tâche ne requiert pas), permissions excessives (identité assortie de plus de privilèges que nécessaire) et autonomie excessive (exécution d'actions à fort impact sans validation humaine).
Sept : identité unique et non partagée, autorisation minimale par tâche, identifiants à courte durée de vie, liste blanche des actions autorisées, limites de volume et de quantité, journalisation complète et immuable de chaque exécution et un mécanisme d'arrêt qui ne nécessite pas le déploiement de code.
Uniquement pour les actions réversibles et à faible impact, et seulement après avoir mesuré sur une période suffisante le pourcentage de propositions approuvées sans modification. La suppression de la validation humaine en raison de contraintes de temps est la cause la plus fréquente d'incidents dans les systèmes multi-agents.
Similaire aux contrôles d'accès humains, mais plus rigoureux : enregistrement documenté, responsable désigné, permissions vérifiables, expiration des identifiants et révision périodique. IBM a constaté en 2025 que le protocole 97% destiné aux organisations confrontées à des incidents liés à l'IA ne disposait pas de contrôles d'accès adéquats.
Savez-vous précisément ce que chaque agent que vous avez déployé peut faire ? Nous auditons le périmètre, les identités, les autorisations et la traçabilité de vos systèmes d'IA, et nous vous fournissons un diagnostic écrit. Demander l'audit → |