Les agences des Five Eyes estiment que la plupart des déploiements d’IA agentique sont déjà trop permissifs

Le 1er mai 2026, la CISA, la NSA et leurs homologues du Royaume-Uni, d’Australie, du Canada et de Nouvelle-Zélande ont publié la première directive de sécurité multigouvernementale coordonnée pour l’IA agentique : « Careful Adoption of Agentic AI Services ». Le message central est sans détour : les infrastructures critiques et les organisations de défense n’évaluent pas un risque futur — elles exploitent déjà des agents disposant d’un accès plus large que leurs propres équipes de sécurité ne peuvent en maîtriser, et ce guide existe parce que cet écart a cessé d’être théorique.

Ce qui rend ce document digne d’une lecture attentive, même si vous n’évoluez pas dans les infrastructures critiques, c’est qu’il constitue la première tentative formelle des agences de sécurité de catégoriser ce qui peut mal tourner avec un agent d’IA — par opposition à une application traditionnelle — et que ces catégories correspondent parfaitement aux erreurs que la plupart des équipes déployant des agents commettent déjà.

Cinq catégories de risques, et pourquoi elles ne se réduisent pas à la « prompt injection »

Le guide divise les risques de l’IA agentique en cinq catégories : privilège, conception et configuration, comportement, structurel et responsabilité. C’est un cadre délibérément plus large que l’accent par défaut de l’industrie de la sécurité sur les injections de prompts et les jailbreaks, et le raisonnement est simple : un agent avec des privilèges étroits et correctement cadrés est bien moins dangereux même en cas de manipulation réussie, car la manipulation n’a nulle part où aller.

Le risque de privilège concerne les agents qui détiennent un accès permanent à des systèmes, des données ou des actions bien au-delà de ce qu’une seule tâche nécessite — l’équivalent IA d’un compte de service avec des droits d’admin de domaine parce que personne n’a pris le temps de le limiter. Le risque de conception et de configuration couvre les agents câblés dans des chaînes d’outils et des sources de données externes sans que personne ne cartographie ce que cette interconnexion expose réellement. Le risque comportemental correspond à l’agent qui fait quelque chose d’involontaire même sans manipulation externe — une action émergente que personne n’a explicitement programmée. Le risque structurel concerne les dépendances en couches que les agents introduisent (un outil ou une source de données compromise devient un agent compromis). Le risque de responsabilité est le plus difficile à rétrofit : lorsqu’un agent prend une action conséquente, peut-on en reconstruire la raison, et qui est responsable qu’elle ait eu lieu.

Le problème de la surface d’attaque interconnectée

Le guide est explicite : le problème de sécurité central de l’IA agentique n’est pas le modèle — c’est le nombre de composants qu’un agent touche typiquement. Un simple agent de service client peut appeler une API CRM, une base de connaissances, un système de tickets et un outil de messagerie, chacun avec ses propres identifiants et modes de défaillance. Le document prévient que cela crée « une surface d’attaque interconnectée que des acteurs malveillants peuvent exploiter », car compromettre un maillon de cette chaîne peut compromettre les permissions effectives de l’agent sur l’ensemble.

C’est exactement le schéma derrière les incidents de sécurité liés aux agents d’IA les plus graves divulgués cette année : les attaquants n’ont pas besoin de casser le modèle lui-même s’ils peuvent compromettre une intégration d’outil faiblement sécurisée et hériter de tout l’accès dont l’agent a bénéficié.

Ce que le guide vous dit vraiment de faire

En enlevant le cadrage, le cœur opérationnel se résume à cinq règles, toutes applicables aujourd’hui avec les outils d’identité et d’accès existants :

N’accordez jamais aux agents un accès large ou sans restriction. Si le compte de service d’un agent peut faire plus que ce que sa liste de tâches documentée requiert, c’est la faille qu’exploiteront les attaquants — et il s’agit généralement d’une faille créée par commodité lors du déploiement initial, non d’une décision délibérée.

Restreignez les agents par défaut à des tâches à faible risque et non sensibles, et exigez une exception explicite et révisée pour étendre le périmètre — inversant ainsi le schéma courant d’un accès large accordé d’emblée et réduit plus tard (ce qui arrive rarement).

Appliquez le moindre privilège avec une authentification par requête, pas un unique identifiant permanent que l’agent conserve toute sa vie. Chaque appel d’outil doit être authentifié et cadré indépendamment, afin qu’une session compromise n’hérite pas d’un accès généralisé.

Exigez une approbation humaine pour les actions à fort impact — transactions financières, suppression de données, modifications des contrôles d’accès, tout ce qui est coûteux ou difficile à annuler. Le guide traite cela comme non négociable, pas comme un supplément optionnel pour les premiers déploiements.

Gérez la sécurité des agents d’IA dans les cadres existants de cybersécurité, pas comme un programme parallèle sur mesure. Les agents doivent figurer dans les mêmes inventaires d’actifs, revues d’accès et playbooks de réponse aux incidents que tout autre composant système avec des identifiants et un accès réseau.

Ce qu’il faut retenir pour les équipes qui déploient des agents ce trimestre

Si vous déployez un agent d’IA en production et que vous ne pouvez pas répondre à la question « quel est le rayon d’explosion maximal si la session de cet agent est compromise maintenant », le guide des Five Eyes indique que vous avez un problème de privilège, pas un problème de modèle. Menez un audit d’accès avant votre prochain déploiement d’agent : listez chaque outil, API et source de données que l’agent peut atteindre, puis demandez-vous si chacun est limité à la permission la plus étroite spécifique à la tâche, plutôt qu’à une autorisation large au niveau service. Cet unique exercice comble le fossé que la plupart des post-mortems d’incidents de cette année ont en commun.