La réponse en 60 secondes
Un assistant IA produit une réponse. Un agent IA peut aller plus loin : il utilise des outils, consulte des données, mémorise un contexte et réalise des actions. Il peut retrouver une livraison, modifier une fiche client, envoyer un email ou commander un équipement connecté.
La question de sécurité n’est donc plus seulement : « Le modèle peut-il se tromper ? » Elle devient : « Que peut faire le système lorsque le modèle se trompe, comprend mal ou se fait manipuler ? »
Une consigne n’est pas une permission. La confiance du modèle n’est pas une autorisation. Avant d’accorder davantage d’autonomie, définissez sa mission, ses outils, son identité, ses sources fiables, ses limites et sa procédure de récupération. Nous appelons cet ensemble le contrat de capacité.
1. Le risque ne porte plus seulement sur la réponse, mais sur sa conséquence
La réponse inexacte d’un chatbot reste normalement à l’écran jusqu’à ce qu’une personne agisse. Un agent réduit cette distance : il peut transformer une décision en appel d’API, modification de données ou action physique. L’erreur devient alors un événement commercial ou opérationnel.
Le même modèle crée donc des risques très différents selon ce qui lui est connecté :
- avec un catalogue en lecture seule, il peut recommander le mauvais produit ;
- avec un CRM ou un paiement, il peut modifier un dossier ou provoquer une perte ;
- avec des droits d’accès ou des équipements, il peut créer un incident de sécurité ou de production.
Le risque dépend des outils, de l’identité et des permissions, de la possibilité d’annuler et de la vitesse de détection.
OWASP décrit cette faiblesse comme une capacité d’action excessive : trop de fonctions, trop de permissions ou trop d’autonomie par rapport à la mission (OWASP LLM06). Le problème commence dans la conception du produit, pas uniquement dans le modèle d’IA.
2. Rédigez un contrat de capacité avant de connecter un outil
Le contrat de capacité précise ce que l’agent peut faire et comment la limite sera imposée par le système.
| Élément du contrat | Question à trancher | Preuve attendue avant lancement |
|---|---|---|
| Mission | Quelle tâche est permise ou interdite ? | Cas d’usage, exclusions et scénarios d’abus |
| Outils | Quel est le minimum nécessaire ? | Outils précis ; fonctions inutiles supprimées |
| Autorité | Au nom de qui l’action est-elle exécutée ? | Identité, permissions et contrôle dans le système cible |
| Informations | Quelles données peuvent influencer l’action ? | Sources autorisées et séparation des contenus externes |
| Dommage maximal | Quelle conséquence reste acceptable ? | Limites de montant, destinataires, dossiers, durée et tentatives |
| Récupération | Comment arrêter ou annuler ? | Aperçu, confirmation, journal, arrêt d’urgence et retour arrière |
Ce contrat transforme « sécuriser l’agent » en exigences vérifiables. Si la valeur attendue exige un compte administrateur partagé, des outils sans limites et aucune possibilité d’annulation, la capacité elle-même doit être réduite.
3. Contrôlez l’action selon sa conséquence, pas selon l’assurance du modèle
Toutes les actions ne nécessitent pas la même friction. Classez-les en quatre niveaux.
Observer
L’agent consulte sans modifier. L’accès doit rester limité et enregistré : la lecture peut exposer des données confidentielles.
Préparer
L’agent prépare un email, un remboursement ou une commande, mais une personne vérifie le résultat avant validation. C’est souvent le bon point de départ.
Agir de manière réversible
L’agent modifie un état, mais l’action peut être annulée. Utilisez des permissions étroites et une procédure testée.
Réaliser une action irréversible ou à fort impact
Paiement, suppression, publication, droits d’accès ou commande physique exigent un contrôle indépendant : validation humaine, règle déterministe, seconde personne autorisée ou service séparé.
La validation doit porter sur l’action et ses paramètres exacts. Elle ne doit pas autoriser une opération ultérieure différente.
Le modèle peut recommander une action. Il ne devrait pas décider seul si cette action est permise. OWASP recommande de faire appliquer l’autorisation par le système qui exécute réellement l’opération (guide OWASP sur la capacité d’action excessive).
4. Prévoyez quatre voies d’attaque, pas seulement une mauvaise question
Des instructions cachées dans un contenu externe
Une page, un document ou un email peut contenir des instructions conçues pour modifier le comportement de l’agent, sans que l’utilisateur les voie.
Traitez les contenus récupérés comme des données non fiables. Séparez-les des consignes internes, limitez leur influence et vérifiez l’action. Le guide OWASP sur la sécurité des agents IA inclut documents, API et emails dans ce périmètre.
Une identité trop puissante
Un agent peut utiliser un compte partagé doté de droits étendus et atteindre des dossiers normalement interdits à l’utilisateur. Exécutez l’action dans le contexte de cette personne lorsque c’est possible. Vérifiez identité, rôle, ressource et opération au moment d’agir.
Une mémoire contaminée
Une information fausse conservée en mémoire peut influencer des tâches ultérieures. Définissez ce qui peut être mémorisé, combien de temps et comment l’inspecter ou le supprimer. Isolez les mémoires entre utilisateurs.
Des enchaînements et des boucles incontrôlés
Les chaînes d’outils peuvent multiplier actions et coûts. Limitez le nombre d’étapes, d’appels, de dossiers, la durée et les dépenses. Arrêtez le processus lorsqu’il dépasse sa mission.
MITRE ATLAS répertorie notamment le détournement d’outils et la contamination du contexte. Utilisez ces comportements pour tester votre scénario réel (MITRE ATLAS).
5. Intégrez la sécurité aux exigences du produit
Chaque capacité doit avoir des critères de sécurité au même titre que ses exigences fonctionnelles.
Ces critères peuvent notamment imposer que :
- les outils n’exposent que les opérations et ressources autorisées ;
- le système cible vérifie l’identité et l’autorisation à chaque action ;
- un contenu externe ne puisse pas devenir silencieusement une consigne ;
- les paramètres soient validés et l’accord lié à l’action affichée ;
- la mémoire dispose de règles de conservation, d’isolation et de suppression ;
- les appels, tentatives, coûts et montants aient des limites techniques ;
- les journaux relient utilisateur, modèle, règle, demande et résultat sans révéler de secrets ;
- l’arrêt, le retour arrière et la gestion d’incident soient testés ;
- les tests de lancement couvrent manipulation, élévation de privilèges, fuite de données et panne d’outil.
Ces contrôles appartiennent au cycle normal de développement. Le cadre SSDF du NIST couvre la préparation, la protection du logiciel, la production de versions sécurisées et la réponse aux vulnérabilités. Adaptez-le au risque de l’entreprise (NIST SSDF).
Pour la gouvernance générale, le NIST AI Risk Management Framework couvre la conception, le développement, l’utilisation et l’évaluation des systèmes d’IA. Sa version 1.0 étant en révision, vérifiez la version actuelle avant de la figer dans une politique (NIST AI RMF).
6. Attribuez les responsabilités dans toute l’entreprise
| Responsable | Décision à prendre en charge |
|---|---|
| Direction produit | Résultat attendu, usages interdits, friction pour l’utilisateur et conséquence acceptable |
| Équipe technique | Conception des outils, identité, permissions, validation et gestion des pannes |
| Cybersécurité | Analyse des menaces, exigences de contrôle, tests d’attaque et critères d’incident |
| Exploitation ou support | Surveillance, suspension, escalade, récupération et retour d’expérience |
| Juridique, DPO et expert métier | Contraintes réglementaires, contractuelles, sectorielles et liées aux données |
Dans une PME, une personne peut cumuler plusieurs rôles. Les décisions doivent néanmoins rester explicites et attribuées.
Les principes « secure by design » de CISA et de ses partenaires demandent aux éditeurs d’intégrer la sécurité dès les décisions produit (CISA et partenaires internationaux). Un agent ne devrait pas transférer cette charge au client par des réglages obscurs ou des permissions trop larges.
7. Dix questions avant de mettre un agent IA en production
- Quelle est l’action la plus lourde de conséquences que cet agent peut réaliser ?
- Quel outil ou quelle permission n’est pas strictement nécessaire ?
- Chaque action utilise-t-elle l’identité du bon utilisateur ou un compte générique puissant ?
- Un contenu externe peut-il influencer une action sans être traité comme non fiable ?
- Quels paramètres exacts la personne voit-elle avant de valider ?
- Quelles actions sont annulables, et l’annulation a-t-elle été testée ?
- Quelles limites empêchent les appels répétés, les montants excessifs ou les coûts incontrôlés ?
- L’équipe peut-elle reconstituer la cause d’une action sans placer de données sensibles dans les journaux ?
- Qui peut suspendre l’agent, et dans quel délai ?
- Quel résultat de test doit bloquer le lancement plutôt que devenir une correction ultérieure ?
Une démonstration prouve seulement que le scénario idéal fonctionne. Le lancement doit aussi couvrir données malveillantes, mauvaises permissions, panne d’outil, changement de modèle et erreur humaine.
Conclusion : l’autonomie doit se gagner capacité par capacité
La sécurité d’un agent IA exige de contrôler tout le parcours : information, décision du modèle, outil, identité, permission, conséquence et récupération.
Commencez par un contrat étroit et l’autorité minimale. N’augmentez l’autonomie que lorsque limites, validations, journaux et récupération fonctionnent en situation d’échec.
L’objectif n’est pas de supprimer toute autonomie. Il est de mettre en place une autonomie dont l’entreprise peut expliquer, limiter et assumer les conséquences.
Avant d’accorder plus d’autonomie, contrôlez le parcours d’action
Apportez-nous un scénario d’agent, ses outils et son action la plus sensible. Nous pouvons cartographier le contrat de capacité, les permissions, les validations et les preuves de lancement - sans transformer un prototype en exercice théorique.
Questions fréquentes
Non. Elle introduit des instructions qui détournent l’agent, mais ce n’est qu’une voie d’échec. Permissions excessives, identité partagée, mémoire mal contrôlée ou outil compromis peuvent suffire.
Non. La validation doit suivre la conséquence. Une action réversible à faible impact peut être automatisée dans des limites imposées. Une action irréversible, financière ou sensible exige un contrôle indépendant.
Son risque de modification est plus faible, mais il peut révéler des informations confidentielles ou accéder à des données hors des droits de l’utilisateur. La lecture doit elle aussi être limitée.
Il peut aider à comprendre l’intention, mais le système cible doit prendre la décision finale à partir de règles déterministes sur l’identité et les permissions.
Lorsque chaque capacité possède des limites définies, des preuves de test, une surveillance, un responsable d’incident et une procédure de récupération utilisable. Une démonstration réussie ou un bon score de test technique ne suffit pas.
Sources primaires vérifiées le 15 juillet 2026. Cet article fournit un cadre général de conception et d’exploitation. Il ne constitue ni une certification de sécurité, ni un test d’intrusion, ni un avis juridique.