Agent IA en entreprise : 7 contrôles avant de lui ouvrir vos outils
Une checklist pour limiter les accès, garder une validation humaine et arrêter proprement un agent qui agit dans le SI.
Un agent agit là où un chatbot répond
Un chatbot produit du texte. Un agent peut aussi lire un CRM, modifier un ticket, appeler une API ou déclencher un workflow. Le risque change dès que le modèle obtient un outil et des droits d’action.
Le NIST travaille en 2026 sur l’identité, l’authentification et l’autorisation des agents. L’objectif est simple : savoir quel agent agit, pour qui, avec quels droits et sur quelle ressource.
1. Donner une identité propre à chaque agent
Un compte partagé empêche d’attribuer une action. Crée une identité technique par agent et par environnement. Les journaux doivent distinguer l’utilisateur, l’agent et le service appelé.
2. Limiter les droits à une tâche précise
Un agent qui classe des demandes n’a pas besoin de supprimer des contacts ni d’exporter toute la base. Commence en lecture seule, puis ajoute chaque permission après un test et une décision documentée.
3. Garder une validation humaine aux bons endroits
L’humain ne doit pas confirmer chaque lecture. Il doit intervenir avant une action qui engage l’entreprise : envoyer un message, publier, payer, modifier la production ou supprimer une donnée.
La validation affiche la cible et le changement exact. Un bouton « confirmer » sans aperçu du résultat ne protège pas grand-chose.
4. Traiter les contenus externes comme des données
Une page web, un email ou un document peut contenir une consigne conçue pour détourner l’agent. Le contenu récupéré ne devient jamais une instruction de confiance.
OWASP consacre désormais des travaux spécifiques aux agents et aux serveurs MCP. Les connexions aux outils doivent être inventoriées, revues et limitées comme n’importe quelle surface d’intégration.
5. Journaliser les décisions et les appels d’outils
Pour comprendre un incident, il faut retrouver la demande, les données consultées, l’outil appelé, les paramètres utiles, la validation reçue et le résultat. Les secrets et les données personnelles inutiles restent hors des logs.
6. Prévoir les doublons, les erreurs et les reprises
Un timeout ne prouve pas qu’une action a échoué. Avant de relancer un paiement, un email ou une écriture, l’agent vérifie si l’effet existe déjà. Une clé d’idempotence, ou un identifiant métier associé à un contrôle d’unicité, permet de détecter une demande déjà traitée avant de répéter son effet.
7. Installer une limite et un arrêt réel
Fixe un plafond d’actions, de durée et de coût. Ajoute une limite de débit et un moyen de couper les accès sans redéployer toute l’application.
L’ANSSI recommande une approche par les risques pour les systèmes intégrant de l’IA. En pratique, le niveau d’autonomie doit suivre l’impact possible, pas la qualité moyenne observée en démonstration.
La revue avant production
Avant l’ouverture à de vrais utilisateurs, une revue courte doit répondre à ces questions :
- Quelles identités et permissions l’agent utilise-t-il ?
- Quelles actions exigent une validation humaine ?
- Quels contenus externes peuvent influencer sa décision ?
- Comment évite-t-on une action en double ?
- Quels événements sont journalisés sans exposer de secret ?
- Quel plafond de coût et de volume s’applique ?
- Qui peut couper l’agent et révoquer ses accès ?
Sources officielles
Sources vérifiées le 20 juillet 2026 en Europe/Paris. Ce texte couvre le produit et la technique. Pour la qualification juridique, consulte un professionnel du droit.
- AI Agent Standards Initiative (ouvre un nouvel onglet)
National Institute of Standards and Technology · mise à jour 20 avril 2026
- Agentic Security Initiative (ouvre un nouvel onglet)
OWASP GenAI Security Project · consulté le 20 juillet 2026
- Développer la confiance dans l’IA par une approche par les risques cyber (ouvre un nouvel onglet)
ANSSI · publié le 6 février 2025
Implémentation d’agents IA