Le contrôle manquant pour les agents IA est une politique d’exécution
Les agents IA deviennent plus faciles à déployer. La semaine dernière, le marché a confirmé cette tendance : nouvelles API de création d’agents, nouveaux produits d’observabilité d’entreprise, plus d’investissements dans l’infrastructure de sécurité des agents. La conséquence pratique pour les responsables sécurité n’est pas que chaque organisation ait soudainement besoin d’une stratégie agent. C’est que plus d’équipes pourront créer des agents avant que les équipes de gouvernance n’aient défini ce que ces agents peuvent réellement faire.
C’est le mauvais ordre.
La plupart des gouvernances IA en entreprise commencent encore par une question de modèle : quel modèle est approuvé, où les données sont stockées, quels prompts sont acceptables ? Ce sont des contrôles utiles. Ils ne suffisent pas quand un système peut récupérer des données, appeler un outil, mettre à jour un enregistrement, envoyer un message ou déclencher un workflow. Un agent peut faire une requête parfaitement conforme à la politique auprès d’un modèle et pourtant créer un résultat inacceptable par l’action qu’il prend ensuite.
Le contrôle manquant est une politique d’exécution : une réponse claire et applicable sur ce qu’un agent peut faire, avec quelle identité, sur quels systèmes, dans quelles conditions, et avec quelles preuves après coup.
Le vrai risque commence après la réponse du modèle
Considérez un assistant achats. Un chatbot classique rédige une comparaison de fournisseurs pour qu’un humain la révise. Une version agentique peut rechercher des contrats, contacter un fournisseur, mettre à jour un système d’achats et préparer une demande d’achat. Le modèle de langage n’est qu’un maillon de cette chaîne. Le risque réside dans la chaîne de décisions et d’effets secondaires.
Cette distinction est importante car les contrôles de sécurité existants peuvent créer une fausse confiance. Une règle de prévention des pertes de données peut empêcher un employé de coller un fichier fiscal dans un chatbot public. Elle ne peut pas décider si un agent interne avec accès légitime doit créer un dossier fournisseur, modifier des détails de paiement ou envoyer des informations commerciales sensibles au mauvais destinataire. Les contrôles d’identité peuvent authentifier l’agent. Ils n’établissent pas à eux seuls si une action est appropriée dans un contexte donné.
C’est pourquoi la gouvernance des agents ne peut pas se réduire à un PDF de politique IA ou un questionnaire fournisseur. Elle doit opérer là où l’action se produit.
Définissez une politique d’exécution avant l’accès en production
Une politique d’exécution doit être suffisamment précise pour qu’un système puisse l’évaluer, pas seulement un principe qui semble sensé en atelier. Pour chaque agent en production, documentez et appliquez cinq éléments.
1. Un responsable métier nommé et un responsable technique nommé
Un agent ne peut pas être la propriété de « l’entreprise ». Le responsable métier accepte le risque du résultat : ce que l’agent doit accomplir, quelles erreurs sont tolérables, quand une revue humaine est requise. Le responsable technique est responsable de l’intégration, des identifiants, de la surveillance et du processus de changement. Sans ces noms, l’agent n’est pas prêt pour la production.
Cela semble basique, mais cela tranche un schéma courant d’IA fantôme : un employé compétent connecte un nouvel agent à un espace de travail partagé ou un outil SaaS parce que cela supprime une étape manuelle. Le workflow peut être utile. Sans propriétaire, personne ne valide l’extension du périmètre ni ne réagit en cas de comportement inattendu.
2. Une liste blanche d’actions restreinte
Commencez par le plus petit ensemble utile d’actions. « Peut accéder à Salesforce » n’est pas un modèle d’autorisation. « Peut lire les opportunités ouvertes dans le territoire assigné et créer une tâche de suivi brouillon » est un modèle d’autorisation.
Rendez la liste blanche explicite au niveau de l’outil et de l’opération. Séparez lecture, brouillon, création, mise à jour, approbation, envoi et suppression. Par défaut, privilégiez l’accès en lecture seule lorsque c’est possible. Exigez une validation humaine pour les actions irréversibles, communications externes, paiements, modifications d’identité et mises à jour de dossiers à fort impact. L’objectif n’est pas de rendre les agents inutiles, mais d’éviter qu’une intégration large ne devienne une délégation large sans contrôle.
3. Conditions contextuelles, pas seulement des permissions statiques
Une permission sûre à 10h peut être risquée en cas d’incident. Un agent support client peut être autorisé à rédiger une réponse mais pas à l’envoyer si le dossier contient des informations juridiques, médicales, financières ou réglementées. Une politique d’exécution doit inclure des conditions telles que classification des données, environnement système, niveau client, plage horaire, valeur de la transaction et seuil de confiance.
Les rôles statiques sont nécessaires. C’est le contexte qui les transforme en contrôle défendable.
4. Une identité d’agent avec des identifiants à durée limitée
Ne faites pas fonctionner un agent via un compte employé partagé ou une clé API permanente copiée dans un outil de workflow. Donnez-lui une identité distincte, un accès au moindre privilège, des jetons limités et un processus d’expiration des identifiants. Cela rend les actions traçables et la révocation pratique.
Cela protège aussi l’organisation d’un mode de défaillance courant : un employé part, un connecteur reste, et une automatisation continue d’agir avec un accès dont personne ne se souvient avoir accordé. Pour les systèmes agentiques, le cycle de vie de l’identité n’est pas une tâche administrative, c’est une partie de la gouvernance en temps réel.
5. Des preuves reliant l’intention à l’action
Enregistrer une requête ne suffit pas. Une piste d’audit utile documente la requête, les données sources utilisées, la version du modèle ou de la politique, l’appel d’outil proposé, le résultat de l’approbation, l’action prise et le résultat. Les équipes sécurité et GRC ont besoin de suffisamment de contexte pour répondre à trois questions après un incident : que savait l’agent, pourquoi a-t-il été autorisé à agir, et qu’est-ce qui a changé ?
C’est là que l’observabilité dépasse le simple tableau de bord. Elle devient la couche de preuve pour une autonomie responsable.
Considérez chaque changement comme une nouvelle décision de risque
Un agent approuvé n’est pas approuvé définitivement. Un nouveau connecteur, une source de données élargie, un changement de modèle, une modification de requête ou un nouveau type d’action peuvent modifier significativement le risque. La gouvernance doit distinguer entre un petit changement de configuration et une extension de l’autorité de l’agent.
Une règle pratique : si un changement permet à l’agent d’accéder à de nouvelles données sensibles, d’agir dans un nouveau système, de communiquer à l’extérieur ou de prendre une décision irréversible, déclenchez une réévaluation légère. Cette réévaluation doit revoir la politique d’exécution, tester les scénarios d’échec, confirmer les contrôles et mettre à jour la validation du responsable.
Cette approche est plus rapide qu’un comité lourd pour chaque ajustement et plus sûre que de traiter tous les changements comme du travail d’ingénierie courant.
Commencez par la découverte, pas par l’interdiction
La dure réalité est que beaucoup des agents les plus impactants n’arriveront pas via le programme formel d’IA. Ils apparaîtront dans les plateformes de workflow, extensions de navigateur, copilotes, outils low-code et add-ons SaaS. Si l’organisation ne gouverne que les agents enregistrés, elle ne gouverne qu’une fraction du comportement réel.
Commencez par découvrir l’usage de l’IA et les intégrations capables d’agents dans toute l’entreprise. Puis classez-les selon l’accès aux données et la capacité d’action. Un assistant de recherche en lecture seule et un agent pouvant modifier les dossiers clients ne doivent pas suivre le même processus de revue. Cette approche basée sur le risque offre aux équipes un chemin sûr pour rendre visibles les automatisations utiles plutôt que de les cacher pour éviter les frictions.
Aona aide les organisations à effectuer cette transition grâce à la découverte de l’utilisation de l’IA, des garde-fous en temps réel et un accompagnement des employés. Si vous définissez vos premiers contrôles d’agents, commencez par un essai de découverte des risques liés à la Gen IA de 90 jours pour identifier l’activité IA à gouverner avant qu’elle ne devienne un incident.
Le but de la gouvernance des agents n’est pas de ralentir l’automatisation, mais de garantir que chaque action automatisée a un propriétaire, une limite et un enregistrement. C’est ainsi que l’IA d’entreprise devient scalable plutôt que simplement rapide.
