Traiter les agents d’IA comme des « assistants inoffensifs » est un désastre en devenir. Si vous ne contrôlez pas leur accès maintenant, votre automatisation finira par devenir un handicap.
À leurs débuts, les modèles LLM n’étaient pas difficiles à contenir. Vous avez donné une invite ; ils répondaient, et si quelque chose n’allait pas, c’était généralement « juste un SMS ». Cela peut prendre la forme d’un résumé qui manque les meilleurs éléments, d’une ligne sourde ou d’une phrase verbeuse.
Mais ensuite, les agents ont été cooptés comme couche de raisonnement centrale au sein des agents d’IA, et la donne a changé du jour au lendemain. Les agents connectent des bases de données et des applications métier, interagissent avec des systèmes externes et exécutent des tâches en plusieurs étapes.
La question n’est donc pas seulement : « Quelle est la capacité du modèle ? » La question la plus importante, à mon avis, est la suivante : « Comment les agents d’IA sont-ils traités et autorisés dans votre environnement ? »
Les échecs qui piquent ne se limitent pas aux moments où un agent débite des inexactitudes ou évoque des hallucinations ; ils se produisent également lorsque l’agent prend des mesures qu’il ne devrait pas prendre, simplement parce qu’il en a la capacité, les autorisations et l’autonomie pour le faire.
Le passage de la réponse à l’exécution
Je constate que l’interopérabilité accélère l’adoption des agents. Des normes telles que le Model Context Protocol (MCP) facilitent la connexion des modèles aux outils et aux sources de données, tandis que les approches agent à agent permettent aux agents d’échanger du contexte, des objectifs et des actions à travers les flux de travail.
Plus de connexions signifie plus de portée, et plus de portée signifie plus de risques que les choses tournent mal.
Alors que les dépenses en IA devraient atteindre 2 500 milliards de dollars en 2026 et que 40 % des applications d’entreprise devraient intégrer des agents d’IA spécifiques à des tâches d’ici la fin de 2026, la vraie question n’est plus celle de l’adoption, mais celle de la visibilité et du contrôle. Avec de tels chiffres, il est clair que l’intégration de l’IA évolue rapidement, mais il existe une faille de sécurité.
Même si les contrôles de sécurité de l’IA rattrapent rapidement leur retard, passant de 37 % en 2025 à 64 % en 2026, cela laisse encore plus d’un tiers sans évaluation formelle. C’est pourquoi les autorisations appropriées sont souvent à la traîne.
Comme je l’ai observé, lorsque les agents opèrent sur plusieurs outils et systèmes, les organisations ne gèrent plus uniquement la « qualité des résultats de l’IA ». Ils gèrent des parcours d’action, souvent dans des environnements où il est difficile de déterminer où une requête a mal tourné, où une entrée a été manipulée ou quelle étape a déclenché l’action finale. Les autorisations, dans ce contexte, font la différence entre une automatisation utile et un comportement non autorisé à grande échelle.
Agence excessive directement proportionnelle à l’autorisation excessive
Les organisations s’inquiètent du niveau d’autonomie que l’IA introduit dans leur cadre opérationnel. Près des trois quarts des organisations déclarent que les agents bénéficient souvent d’un accès plus large que nécessaire. C’est cette agence excessive qui doit être maîtrisée.
En pratique, une autonomie non contrôlée au sein d’un flux de travail particulier signifie que l’agent peut accéder aux systèmes dont il n’a pas besoin, exécuter des actions en dehors de son rôle prédéterminé et interagir avec des systèmes externes au-delà des paramètres prédéfinis. Cela signifie que les organisations ne considèrent pas seulement une « mauvaise réponse » comme le plus grand risque, mais aussi une « action non autorisée ». Cette action peut impliquer une exposition involontaire de données, des commandes non autorisées ou des modifications ayant un impact sur l’intégrité et difficiles à annuler.
Les autorisations excessives sont une bête sournoise. Je l’ai vu s’infiltrer lentement dans les flux de travail d’IA agentique, généralement motivés par trois facteurs communs :
- Les responsables, dans leur « sagesse », activent une large gamme d’outils/API pour rendre l’agent encore plus utile.
- Il peut y avoir des problèmes d’intégration et un accès élevé est accordé pour que l’intégration fonctionne correctement, ce qui signifie des autorisations supplémentaires dépassant le seuil d’utilisation sécurisée.
- Les agents peuvent prendre des décisions avec moins de points de contrôle humains, notamment pour les actions qui ont un impact tangible. Cela peut provenir d’une confiance aveugle dans l’IA et d’une volonté d’être une entreprise axée sur l’exécution.
3 risques systémiques dans les workflows d’IA agentique
Moins de la moitié des entreprises ont adopté des cadres formels de gestion des risques pour l’IA, et je pense que c’est là que commence le véritable défi de l’IA agentique. Il ne s’agit pas de ce qu’il peut faire, mais du fait que ses actions deviennent plus difficiles à observer et à gouverner une fois qu’il opère sur des systèmes connectés.
Premièrement, de nombreux modèles sont en réalité des boîtes noires. L’opacité du fonctionnement interne rend plus difficile la vérification des résultats, l’explication des décisions ou l’audit en toute confiance de ce qui s’est passé après coup.
Deuxièmement, la capacité invite à une dépendance excessive. Dans les conversations que j’ai eues avec les RSSI, un thème cohérent émerge. Alors que les agents semblent « s’en occuper », les humains reculent et les critiques s’amenuisent. Le résultat est que les erreurs et les préjugés persistent plus longtemps parce que moins de personnes surveillent de près, ce qui est particulièrement dangereux dans les environnements à enjeux élevés.
Troisièmement, les attaquants n’ont pas besoin de compromettre le modèle lui-même s’ils peuvent compromettre ce que lit l’agent ou les services qui l’alimentent. Les flux de travail connectés créent des modes d’attaque de type chaîne d’approvisionnement, où la manipulation en amont devient le levier.
Le chemin vers la réautorisation : agence de contrôle
La réautorisation ne consiste pas à limiter l’autonomie des agents d’IA, mais plutôt à les contrôler de manière appropriée. Les agents d’IA s’exécutent, et nous avons besoin qu’ils s’exécutent bien, mais nous devons mettre en œuvre un audit continu des autorisations pour identifier les agents qui gravissent lentement les échelons de « l’agence ».
Les organisations doivent disposer d’une visibilité complète pour pouvoir évaluer les interactions d’IA agentique, signaler les comportements irréguliers, vérifier si les autorisations sont conformes à la politique et utiliser des exercices réels sur table, tels que des tests d’injection rapide, pour se prémunir contre les vulnérabilités. Abonnez-vous également à un flux de travail humain dans lequel la surveillance humaine est obligatoire lorsque des données sensibles, des décisions financières, des modifications d’accès ou des mises à jour opérationnelles majeures sont impliquées.
Il faut également éviter de donner des outils aux agents « juste au cas où ils en auraient besoin ». Au lieu de cela, implémentez le partage de contexte selon le principe du moindre privilège, en limitant la vue et l’accès aux outils de l’agent à ce dont la tâche a réellement besoin.
Enfin, permettez-moi de souligner qu’il ne faut pas oublier la chaîne d’approvisionnement de l’IA des agents qui comprend l’intégration, les bibliothèques, les API et les tiers. Ceux-ci doivent être vérifiés, corrigés et sécurisés avec des contrôles réseau stricts pour créer un écosystème fiable et réduire le risque de manipulation en amont.
Si les agents de l’IA sont traités comme des assistants inoffensifs, ils seront autorisés à le faire comme des assistants inoffensifs, et le libre arbitre excessif deviendra normal.
Nous devons freiner l’inévitabilité d’une autonomie incontrôlée. Prenez le contrôle de fonctionnalités et d’autorisations plus larges ; se concentrer sur l’instauration d’une surveillance là où cela est important. Les agents peuvent améliorer les opérations, mais seulement s’ils sont gouvernés en tant qu’acteurs au sein de garde-fous et ne font pas confiance par défaut.
Cet article est publié dans le cadre du Foundry Expert Contributor Network.
Voulez-vous nous rejoindre ?
