Un agent IA n’est jamais plus dangereux que les accès qu’on lui donne. Contrairement à un chatbot qui se contente de répondre, un agent lit des fichiers, interroge des bases, envoie des e-mails et déclenche des actions dans vos outils. La question n’est donc pas seulement « que sait le modèle ? ». C’est aussi « à quoi peut-il toucher, et au nom de qui ? ».

Les recommandations de l’OWASP et de l’ANSSI permettent de cadrer ces accès, pour qu’un agent ne voie et ne fasse que ce qu’il est autorisé à voir et à faire.

Les trois façons dont un agent déborde

Le projet OWASP GenAI Security classe l’« agentivité excessive » (LLM06) dans le Top 10 2025 des risques des applications fondées sur des grands modèles de langage (LLM). Il la définit comme la faille qui permet à un système d’exécuter des actions dommageables à partir de réponses du modèle inattendues, ambiguës ou manipulées. Il en identifie trois causes.

Trop de fonctions. L’agent dispose d’outils dont sa mission n’a pas besoin. L’OWASP prend l’exemple d’une extension choisie pour lire des documents, qui permet aussi de les modifier et de les supprimer.

Trop de permissions. Les outils ont plus de droits que nécessaire sur les systèmes connectés. Par exemple, un outil de lecture se connecte à la base de données avec une identité autorisée à modifier, insérer et supprimer.

Trop d’autonomie. Les actions à fort impact ne sont ni vérifiées ni approuvées. C’est le cas d’un outil qui supprime des documents sans confirmation de l’utilisateur.

Parmi les déclencheurs, l’OWASP cite les hallucinations et l’injection de prompt, directe ou indirecte, qui occupe la première place de son classement (LLM01). L’ANSSI décrit aussi l’injection indirecte, cachée dans le contenu d’un e-mail reçu ou d’une page web. D’où la règle posée par l’OWASP dans sa fiche LLM07 : les contrôles critiques, comme la séparation des privilèges ou les vérifications d’autorisation, ne doivent jamais être délégués au modèle.

Règle n°1 : le minimum d’outils, le minimum de droits

L’OWASP formule quatre recommandations directement applicables (LLM06).

  1. Limiter les extensions. L’agent ne reçoit que les outils strictement nécessaires. S’il n’a pas besoin de récupérer le contenu d’une URL, cet outil ne doit pas lui être proposé.
  2. Limiter les fonctions de chaque extension. Un outil qui résume les e-mails n’a besoin que de les lire, pas de les envoyer ni de les supprimer.
  3. Éviter les outils ouverts. Plutôt qu’une commande système ou un accès à n’importe quelle URL, mieux vaut construire un outil spécifique, par exemple un outil qui ne fait qu’écrire dans un fichier.
  4. Limiter les permissions. Un agent qui consulte une base produits pour faire des recommandations n’a besoin que de lire la table « produits ». Ces droits s’appliquent à l’identité que l’outil utilise pour se connecter, au niveau de la base elle-même.

Si les tâches d’un agent demandent des niveaux d’accès différents, l’OWASP recommande d’utiliser plusieurs agents, chacun avec le moindre privilège nécessaire (LLM07).

Reste la question des secrets. L’ANSSI demande une gestion sécurisée des secrets à toutes les phases du projet (R5). Elle privilégie les jetons d’authentification temporaires pour les opérations à privilèges (R10). L’OWASP ajoute qu’aucun identifiant, clé d’API ou chaîne de connexion ne doit figurer dans le prompt système (LLM07).

Règle n°2 : l’agent ne voit que ce que voit l’utilisateur

L’OWASP décrit un cas typique de permissions excessives. Un outil censé lire les documents de l’utilisateur courant se connecte au dépôt avec un compte privilégié, qui accède aux fichiers de tous les utilisateurs. L’ANSSI pose le principe inverse : le système d’IA doit intégrer les droits d’accès et le « besoin d’en connaître » dans les réponses qu’il apporte.

Pour les actions. Les actions faites au nom d’un utilisateur s’exécutent dans le contexte de cet utilisateur, avec le minimum de privilèges (OWASP LLM06). Un outil qui lit le dépôt de code d’un utilisateur doit ainsi lui demander de s’authentifier via OAuth, avec le périmètre minimal.

Pour la recherche documentaire. Dans un système RAG, l’OWASP recommande une base vectorielle qui tient compte des permissions. Il préconise des contrôles d’accès fins et un cloisonnement logique strict entre groupes d’utilisateurs. Il conseille aussi d’étiqueter et de classifier les données pour contrôler les niveaux d’accès (LLM08). L’ANSSI précise que cette gestion des droits est possible sur les données additionnelles, mais qu’elle dépend des outils de stockage utilisés.

Pour les données d’entraînement. L’ANSSI rappelle qu’on ne peut pas gérer de droits d’accès sur les données apprises par un modèle. Elle recommande donc de n’entraîner un modèle qu’avec des données légitimement accessibles à ses utilisateurs (R18).

Le principe à retenir est celui de la médiation complète (OWASP LLM06). L’autorisation est appliquée par les systèmes en aval, et non laissée à l’appréciation du modèle. Chaque requête envoyée par l’agent est vérifiée au regard des politiques de sécurité.

Règle n°3 : un humain sur les actions critiques, des filtres autour du modèle

Même bien cadré, un agent peut se tromper ou être manipulé. Les deux référentiels prévoient donc des barrières extérieures au modèle.

La validation humaine. L’OWASP recommande qu’un humain approuve les actions à fort impact avant leur exécution (LLM06). L’ANSSI va plus loin : un système d’IA ne doit pas pouvoir exécuter automatiquement d’actions critiques (R9). Elle cite les transactions bancaires, la production de contenu public, la création d’utilisateurs à privilèges ou la reconfiguration de composants réseau.

La prudence avec les entrées non maîtrisées. L’ANSSI recommande de limiter, voire de proscrire, les actions automatiques déclenchées à partir de données issues d’Internet ou d’e-mails (R27). L’OWASP décrit le scénario type. Un e-mail piégé pousse un assistant à chercher des informations sensibles dans la boîte de réception, puis à les transférer à l’attaquant. Les parades citées : un outil limité à la lecture, un accès OAuth en lecture seule, une validation manuelle de chaque envoi.

Des flux maîtrisés. Toutes les interactions de l’agent avec les applications métier sont documentées et validées. Les flux sont filtrés, chiffrés, authentifiés et journalisés. Ils contrôlent les autorisations en plus de l’authentification (ANSSI R26).

Des filtres en entrée et en sortie. L’ANSSI recommande de filtrer les requêtes malveillantes et celles qui ne sont pas légitimes d’un point de vue métier. Elle conseille aussi de retirer des réponses les informations définies comme sensibles, comme des coordonnées personnelles, et de limiter leur taille (R25).

Une limite de débit. Plafonner le nombre d’actions sur une période donne le temps de repérer une dérive avant qu’elle ne cause des dégâts importants (OWASP LLM06).

Le cloisonnement. L’ANSSI recommande d’isoler le système d’IA dans des zones dédiées. Un attaquant qui l’aurait compromis ne pourrait pas se propager facilement (R28).

Règle n°4 : tout journaliser et revoir les droits

L’objectif fixé par l’ANSSI : pouvoir reconstituer entièrement un événement en cas d’incident.

Journaliser chaque étape. L’ANSSI liste ce qu’il faut tracer (R29) : les requêtes des utilisateurs, les traitements appliqués avant l’envoi au modèle, les appels aux plugins, les accès aux données additionnelles, les filtres en sortie et les réponses. L’OWASP recommande des journaux détaillés et immuables des recherches dans la base documentaire (LLM08).

Surveiller. L’OWASP conseille de journaliser et de surveiller l’activité des outils et des systèmes connectés, pour repérer les actions indésirables et réagir (LLM06).

Revoir les droits. Pour les outils d’IA tiers connectés à la messagerie, aux documents ou au code, l’ANSSI recommande une revue des droits dès l’activation, puis régulièrement, par exemple tous les mois (R35). Le but est de vérifier que les réglages par défaut ou les mises à jour n’ouvrent pas trop l’accès.

Prévoir un plan B. L’ANSSI recommande de garder un mode dégradé sans IA, pour assurer les besoins métier en cas de défaillance (R15).

Les journaux contiennent eux-mêmes des données d’utilisateurs. L’ANSSI rappelle qu’ils doivent respecter les exigences de la CNIL, notamment sur la durée de conservation.

La liste de vérification avant la mise en production

Ces règles ne sont pas réservées aux grandes entreprises. Les agents grand public, comme Muse de Meta, ou les outils marketing pilotables par agent comme Klaviyo, posent exactement les mêmes questions. Un agent vaut ce que valent les droits qu’on lui accorde sur les données. La vraie question n’est pas de savoir s’il est assez intelligent pour qu’on lui fasse confiance, mais si l’on saura reconstituer ce qu’il a fait le jour où il se trompera.

Sources

Toutes les recommandations ci-dessus sont tirées de ces textes officiels :