Gouvernance des agents IA : 7 contrôles avant la mise en production

Un agent IA n’est pas un simple chatbot

Un chatbot produit une réponse. Un agent peut aussi rechercher une information, choisir un outil, appeler une API, modifier un dossier ou déclencher une étape de processus. Ce passage de la réponse à l’action change la nature du risque.

Le sujet n’est donc pas seulement de savoir si le modèle répond correctement. Il faut aussi savoir ce qu’il peut lire, ce qu’il peut modifier, au nom de qui il agit et comment interrompre son exécution.

La CNIL souligne que les systèmes agentiques font circuler des données entre de multiples services et rendent le partage des responsabilités plus complexe. Pour une entreprise, la gouvernance doit commencer avant que l’agent obtienne ses premiers accès de production.

Adapter l’autonomie au risque de l’action

Toutes les actions ne nécessitent pas le même niveau de contrôle. Lire une base documentaire approuvée n’a pas le même impact qu’envoyer un email à un client, modifier un prix ou déclencher un paiement.

Un cadre simple consiste à distinguer trois modes : recommandation, exécution après validation humaine et exécution autonome. Le niveau d’autonomie augmente uniquement lorsque le processus, les données et les mécanismes de récupération sont suffisamment maîtrisés.

• Faible risque : recherche, classement ou préparation d’un brouillon, sans modification du système source.
• Risque intermédiaire : création ou mise à jour réversible, avec règles déterministes et contrôle a posteriori.
• Risque élevé : communication externe, décision financière, suppression ou action irréversible, avec validation humaine obligatoire.

1. Appliquer le principe du moindre privilège

Un agent ne doit disposer que des données, outils et opérations nécessaires à sa mission. Un agent chargé de préparer un résumé de tickets peut avoir besoin de lire les tickets ; il n’a pas besoin de les supprimer ni d’accéder à toute la base clients.

OWASP classe l’excès d’autonomie parmi les risques majeurs des applications basées sur les LLM et recommande des permissions minimales, liées au contexte de l’utilisateur. Cette règle doit être imposée par les systèmes d’autorisation, pas seulement écrite dans le prompt. Voir le cadre OWASP sur l’excessive agency.

• Commencer en lecture seule.
• Autoriser explicitement chaque outil et chaque opération.
• Limiter les périmètres de données par rôle, équipe ou client.
• Réexaminer les droits après chaque évolution du cas d’usage.

2. Séparer les comptes et les environnements

Un agent de test ne doit pas partager les mêmes identifiants qu’un agent de production. Il doit disposer de sa propre identité technique, de secrets dédiés et d’un environnement isolé. Cette séparation réduit le rayon d’impact d’une erreur ou d’une compromission.

Pour un processus de support, on peut tester l’agent sur des demandes anonymisées et un CRM de démonstration. L’accès au CRM réel n’arrive qu’après validation des scénarios, avec un compte de service distinct et révocable.

• Identité unique par agent et par environnement.
• Aucun identifiant personnel partagé avec l’agent.
• Données de test séparées des données réelles.
• Accès réseau limité aux services indispensables.

3. Placer la validation humaine au bon endroit

La validation humaine ne doit pas être ajoutée à chaque micro-action. Une succession d’approbations routinières crée de la fatigue et finit par devenir un simple clic automatique. Elle doit protéger les moments où une décision peut réellement produire un dommage.

Avant un envoi externe, une modification financière ou une suppression, l’utilisateur doit voir l’action proposée, ses paramètres et son effet attendu. L’approbation doit être liée à cette action précise et expirer si les paramètres changent.

• Prévisualiser le message, le montant ou la modification.
• Identifier clairement l’approbateur responsable.
• Refuser l’exécution si l’approbation manque ou n’est plus valide.
• Conserver la preuve de la validation avec l’action exécutée.

4. Journaliser les décisions, les outils et les résultats

Un historique de conversation ne suffit pas. Pour comprendre un incident, l’entreprise doit pouvoir reconstituer la demande initiale, les sources consultées, les outils appelés, les paramètres utilisés, les validations reçues et le résultat de chaque action.

La checklist de sécurité OWASP pour les agents IA recommande de journaliser les décisions, appels d’outils et résultats, tout en évitant d’inscrire des données sensibles ou des secrets en clair.

• Attribuer un identifiant à chaque exécution.
• Relier l’action à l’utilisateur ou au processus qui l’a déclenchée.
• Conserver les refus, erreurs, reprises et interventions humaines.
• Définir une durée de conservation adaptée aux besoins réels.

5. Fixer des limites de dépenses, de volume et d’actions

Un agent peut entrer dans une boucle, multiplier les appels ou répéter une action après un échec mal interprété. Les limites opérationnelles protègent à la fois le budget et le processus métier.

Pour un agent de qualification commerciale, les limites peuvent porter sur le nombre de fiches traitées, le nombre d’emails préparés, les appels API ou la dépense maximale par journée. Une anomalie doit suspendre le flux plutôt que déclencher davantage de tentatives.

• Plafond de coût et de tokens par exécution.
• Nombre maximal d’actions, d’appels d’outils et de tentatives.
• Limites métier : montant, volume, destinataires ou fréquence.
• Alerte automatique lorsque le comportement sort de la normale.

6. Protéger les données et les secrets

Les clés API, mots de passe et jetons d’accès ne doivent jamais être copiés dans les instructions de l’agent. Ils doivent être conservés dans un gestionnaire de secrets et fournis uniquement au composant qui exécute l’action autorisée.

Il faut également cartographier les données que l’agent reçoit, les services auxquels elles sont transmises, les journaux où elles apparaissent et les éventuelles mémoires persistantes. Une politique de conservation du fournisseur ne remplace pas cette cartographie.

• Classer les données avant de les connecter à l’agent.
• Masquer ou supprimer les informations inutiles.
• Chiffrer les secrets et organiser leur rotation.
• Vérifier les règles de conservation, d’hébergement et de sous-traitance.

7. Prévoir l’arrêt, la reprise et la gestion d’incident

Le bouton d’arrêt ne doit pas être une idée ajoutée après le déploiement. L’équipe doit pouvoir suspendre un agent, révoquer ses accès et empêcher la reprise automatique d’une action dangereuse.

La procédure d’incident précise qui décide de l’arrêt, comment les accès sont coupés, comment les actions déjà exécutées sont identifiées et quelles opérations peuvent être annulées. Les scénarios doivent être testés avant la production, comme n’importe quelle procédure de continuité.

• Arrêt manuel immédiatement accessible.
• Circuit breaker automatique sur anomalie ou dépassement.
• Révocation centralisée des identités et des secrets.
• Plan de reprise, de correction et d’information des parties concernées.

Checklist avant la mise en production

Cette liste ne remplace pas une analyse de risque complète. Elle permet toutefois de bloquer les lacunes les plus fréquentes avant de donner à un agent un accès réel aux opérations.

• Le propriétaire métier et le responsable technique sont identifiés.
• Le périmètre, les données et les actions autorisées sont documentés.
• L’agent utilise une identité dédiée avec des droits minimaux.
• Les environnements de test et de production sont séparés.
• Les actions sensibles nécessitent une validation explicite.
• Chaque appel d’outil et chaque résultat sont traçables.
• Des limites de coût, de volume, de durée et de tentatives sont actives.
• Les secrets sont gérés hors des prompts et des journaux.
• L’arrêt et la révocation des accès ont été testés.
• Une personne sait quoi faire lorsque l’agent échoue ou se comporte anormalement.

Commencer par un processus contrôlé

La bonne première mise en production n’est généralement pas le processus le plus spectaculaire. C’est un processus fréquent, suffisamment délimité, dont les actions et les exceptions peuvent être observées.

Un agent peut d’abord préparer une recommandation, puis exécuter certaines actions réversibles après validation. Son autonomie augmente uniquement lorsque les preuves de fiabilité et les contrôles suivent. Cette approche rejoint la méthode NOVENZA : clarifier le processus, construire un périmètre contrôlé et étendre progressivement.