Les limites d’un agent IA ne s’écrivent pas dans le prompt. Elles s’écrivent dans le modèle de permissions. La règle pratique publiée par Meta en novembre 2025, la Agents Rule of Two, énonce qu’un agent ne devrait satisfaire au plus que deux propriétés sur trois : traiter des entrées non fiables, accéder à des données sensibles, et modifier un état ou communiquer vers l’extérieur. Un agent qui réunit les trois peut être transformé en outil d’exfiltration de données par un simple texte injecté. Un modèle de permissions qui fonctionne opère sur quatre couches — identité, outil, argument et budget — et marque à l’avance les actions irréversibles pour validation humaine.
Pourquoi un prompt n’est pas un contrôle de sécurité
L’instruction la plus fréquente que nous trouvons dans les projets dont nous héritons ressemble à ceci : ne pas supprimer de clients, ne pas envoyer d’email sans validation, ne pas exposer d’informations internes. Cette phrase figure dans le prompt système et donne l’impression d’une protection. Elle n’en est pas une.
Un prompt est une suggestion statistique, pas une permission. Il entre en concurrence pour l’attention du modèle avec tous les autres textes présents dans le contexte — y compris ceux venus de l’extérieur. Dès que l’agent lit un email, une page web, un fichier déposé par un client ou un résultat d’outil, ce texte occupe le même espace que vos instructions. C’est toute l’idée de l’injection de prompt, et c’est pourquoi aucune formulation ne permet de s’en sortir.
La bonne séparation est simple : le prompt définit l’intention, le modèle de permissions définit la capacité. Ce que l’agent ne peut techniquement pas faire, il ne le fera pas — quelle que soit la conviction avec laquelle on le persuade qu’il le devrait.
Test rapide : si votre seule défense contre une action destructrice est une phrase dans un prompt, vous n’avez pas de défense. Vous avez une demande polie.
La Rule of Two : le cadre le plus pratique publié à ce jour
Le 1er novembre 2025, Meta a publié un cadre d’une simplicité inhabituelle pour concevoir des agents plus sûrs. Il identifie trois propriétés et pose qu’un agent, au sein d’une même session, ne devrait en satisfaire au plus que deux.
| Propriété | Ce que cela signifie | Exemple typique |
|---|---|---|
| A. Entrée non fiable | L’agent lit un contenu contrôlé par quelqu’un d’autre | Emails entrants, formulaires, pages web, documents déposés |
| B. Accès à des données sensibles | L’agent peut lire des données privées ou des systèmes internes | CRM, paie, base de connaissances interne, boîte mail |
| C. Changement d’état ou communication externe | L’agent peut écrire, envoyer ou publier | Envoi d’email, appel d’une API externe, mise à jour d’un enregistrement, prélèvement |
Le danger réside dans la combinaison des trois. Un agent qui lit un email entrant (A), extrait des données client du CRM (B) et peut envoyer des emails (C) devient une machine à exfiltrer dès que quelqu’un lui envoie un message contenant une instruction cachée. L’attaquant n’a rien à casser ; il lui suffit d’écrire du texte.
Meta souligne elle-même que cette règle n’est pas une ligne d’arrivée. Elle ne protège ni contre les erreurs de l’agent, ni contre les injections qui se contentent de produire de la désinformation dans la réponse, ni contre des permissions trop larges à l’intérieur des deux axes conservés. C’est un outil pour réduire le pire scénario, pas un substitut à une défense en profondeur.
Comment casser la combinaison en pratique
Dans la plupart des cas, vous n’avez pas à renoncer à une capacité ; vous devez la répartir entre deux agents ou deux étapes. Voici les trois patterns qui fonctionnent.
| Pattern | Ce qui est séparé | Quand l’utiliser |
|---|---|---|
| Lecteur et exécutant | Un agent lit l’entrée non fiable et ne renvoie qu’un résumé structuré ; un second agent agit sur ce résumé face aux systèmes réels | Traitement d’emails, formulaires, documents clients |
| Signature humaine | L’agent réunit les trois propriétés, mais l’action C passe par une validation humaine | Quand le processus ne peut réellement pas être scindé |
| Canal de sortie fermé | L’agent ne peut écrire que vers des destinations figurant sur une liste blanche fixe | Reporting interne, mise à jour d’enregistrements, génération de brouillons |
Le deuxième pattern est le plus courant, et c’est aussi celui qui se dégrade : une validation devenue réflexe cesse d’être un contrôle. Où placer exactement le point de validation, et comment le garder utile, est traité dans notre guide sur la validation humaine.
Un modèle de permissions en quatre couches
La permission d’un agent n’est pas une question binaire d’accès aux systèmes. Elle se construit en quatre couches, et chaque couche omise ouvre toute une classe de défaillances.
| Couche | La question à laquelle elle répond | Ce qui se produit quand elle manque |
|---|---|---|
| Identité | Au nom de qui l’agent agit | Des actions attribuées à un compte de service anonyme ; aucune piste d’audit, aucune reconstitution |
| Outil | Quelles actions existent pour lui | L’agent découvre une capacité qu’il n’était pas censé avoir, comme la suppression via un outil de mise à jour générique |
| Argument | Sur quoi il peut exécuter cette action | Bon outil, mauvaise portée — une mise à jour appliquée à tous les enregistrements au lieu d’un seul |
| Budget | Combien, à quelle vitesse et jusqu’à quand | Une boucle qui enchaîne des centaines d’étapes ou des milliers d’appels avant que quiconque s’en aperçoive |
La couche argument est celle qu’on oublie le plus souvent, et celle qui cause l’essentiel des dégâts réels. Un agent autorisé à mettre à jour le statut d’une commande sans limite de portée peut mettre à jour toutes les commandes. La règle simple : chaque outil d’écriture valide ses arguments côté serveur, pas dans des instructions au modèle.
Injection de prompt et détournement d’outils : ce qui s’est déjà produit
En décembre 2025, l’OWASP a publié son Top 10 des risques pour les applications agentiques. Le risque référencé ASI02, Tool Misuse and Exploitation, décrit exactement le cas où un agent utilise un outil autorisé de façon destructrice — et la mitigation recommandée est une permission granulaire et une validation stricte des arguments avant exécution. Ce n’est pas une recommandation théorique.
Un exemple concret : la CVE-2025-59528 dans Flowise, une plateforme low-code de construction d’applications agentiques, provenait d’un traitement non sécurisé des données de configuration CustomMCP et permettait l’injection et l’exécution de JavaScript arbitraire. La faille n’était pas dans le modèle. Elle était dans la couche entre le modèle et les outils — précisément l’endroit que la plupart des équipes considèrent comme de la tuyauterie.
La spécification elle-même va dans le même sens : la révision stable du Model Context Protocol datée du 28 juillet 2026 place le renforcement de l’autorisation parmi ses changements majeurs, aux côtés du passage à un protocole sans état. Qui construit aujourd’hui une couche d’outils part d’une meilleure base qu’il y a un an, mais cette base ne remplace pas vos propres décisions.
Ce qu’un agent ne fait jamais seul
La liste qui suit est indépendante du secteur. Ce sont des actions dont le coût d’une erreur dépasse le coût de la friction.
- Déplacer de l’argent. Prélever, créditer, rembourser, modifier des conditions de paiement.
- Communiquer vers l’extérieur au nom de l’entreprise. Email client, messages, publication — rédiger oui, envoyer non.
- Supprimer ou toute action irréversible. Tout ce qui n’a pas de bouton d’annulation.
- Modifier des permissions. Un agent capable d’élargir ses propres permissions n’est pas un agent, c’est une faille.
- Agir à large portée. Mises à jour en masse, exports de base de données, changements de configuration système.
- Décisions à conséquence juridique ou réglementaire. Refuser un sinistre, classer un salarié, engager un prix ferme.
Ce qu’un agent a le droit de lire est une question distincte et tout aussi importante — la classification des informations que vous pouvez confier à un modèle est traitée dans notre guide de classification des données en entreprise.
À quoi cela ressemble quand c’est bien fait
Un bon modèle de permissions est ennuyeux. Il ressemble à un tableau : chaque outil a un propriétaire, un niveau de risque, une plage d’arguments autorisée, un plafond d’appels quotidiens et un indicateur précisant s’il requiert une validation. Ce tableau s’écrit avant le premier prompt et se relit à chaque changement.
Trois tests à mener sur n’importe quel agent avant la production : tenter d’injecter une instruction par chaque canal d’entrée non fiable et vérifier qu’elle n’atteint jamais un outil d’écriture ; exécuter chaque outil d’écriture avec un argument hors plage et vérifier qu’il est rejeté côté serveur ; et lancer l’agent sur un objectif impossible et vérifier qu’il s’arrête au plafond de budget au lieu de continuer. La méthode complète de ces tests figure dans notre guide d’évaluation, et la structure sur laquelle tout repose est expliquée dans Anatomie d’un agent IA d’entreprise.
Questions fréquentes
Qu’est-ce que la Rule of Two de Meta ?
Un cadre de sécurité publié par Meta en novembre 2025 selon lequel un agent, au sein d’une même session, ne devrait satisfaire au plus que deux propriétés sur trois : traiter des entrées non fiables, accéder à des données sensibles, et pouvoir modifier un état ou communiquer vers l’extérieur. Réunir les trois transforme une simple injection de prompt en fuite de données.
Peut-on empêcher totalement l’injection de prompt ?
Pas avec les méthodes disponibles aujourd’hui. Tout texte qui entre dans le contexte entre en concurrence pour l’attention du modèle, y compris un texte de source externe. La défense n’est donc pas la prévention mais la limitation des dégâts : permissions minimales, séparation entre la lecture de l’entrée et l’exécution des actions, et validation humaine pour les étapes irréversibles.
Quelle différence entre les permissions d’un utilisateur et celles d’un agent ?
Les permissions d’un utilisateur sont vérifiées une fois à la connexion et supposent un jugement humain tout au long de la session. Celles d’un agent doivent être vérifiées à chaque appel, au niveau de l’outil et au niveau de l’argument, parce qu’il n’y a aucun jugement humain entre les étapes. En pratique, cela signifie une validation côté serveur plutôt qu’une confiance dans les instructions données au modèle.
Comment restreindre un agent sans le rendre inutile ?
Scinder plutôt que bloquer. Un agent lecteur qui renvoie un résumé structuré, plus un agent exécutant qui n’agit que sur ce résumé, préserve toute la capacité métier tout en éliminant la combinaison dangereuse. Là où la scission est impossible, ajoutez un point de validation sur la seule action sortante.
À qui doit revenir le modèle de permissions ?
À celui qui en assume les conséquences si une mauvaise action part — en général le propriétaire du processus métier, pas l’équipe de développement. L’équipe technique l’implémente, mais décider quelles actions sont irréversibles et lesquelles requièrent une validation est une décision métier.
Pour aller plus loin
Faire tourner des agents IA sur votre propre infrastructure – Là où les limites de permission sont réellement appliquées, une fois que l’agent parle à de vrais outils.
Comment évaluer un agent avant de l’exposer à un client – La méthode pour vérifier que les limites tiennent, exécution après exécution.