IA agentique : ce que recommande l’ANSSI depuis le 30 octobre

Le guide appartient à la collection Les Essentiels, qui s’adresse d’abord aux professionnels de la cybersécurité : RSSI, architectes, experts[1]. Il vise « les organisations qui déploient, configurent ou intègrent un système agentique, y compris des produits sur étagère dont elles maîtrisent la configuration et les connecteurs ». L’entreprise qui active un agent dans sa suite bureautique ou dans son CRM est donc concernée au même titre que celle qui développe le sien.

Ce sont des recommandations. L’ANSSI précise que ses Essentiels reflètent sa position au moment de leur publication et pourront être mis à jour ; le document porte la mention V1.0. Écrire « l’ANSSI exige » serait donc faux ; « l’ANSSI recommande, et voici ce que nous en faisons » est plus juste.

Les sept principes, et la décision que chacun appelle :

La phrase qui ouvre le guide en donne la clé. Sécuriser un agent « repose sur le cloisonnement de ce système, la maîtrise des accès et des contrôles déterministes que les traitements agentiques ne doivent pas pouvoir outrepasser »[1]. Déterministe veut dire ici : une règle qui donne toujours la même réponse à la même demande, comme un contrôle d’accès, et non un modèle qui juge au cas par cas.

Le guide ajoute aussitôt : « une action autorisée peut être dommageable ». Un agent peut se tromper, être manipulé ou combiner des opérations permises dont l’enchaînement ne l’est pas. Le contrôle doit donc porter sur ce que l’agent fait, pas seulement sur ce qu’il a le droit de faire.

L’ANSSI n’est pas seule sur cette ligne. Le NCSC britannique écrivait en décembre 2025 que l’injection de prompt ne sera peut-être jamais neutralisée comme l’injection SQL l’a été, et qu’il faut donc en réduire le risque et l’impact par des garde-fous déterministes qui bornent les actions du système[2]. En avril 2026, le CERT-FR notait déjà qu’une formulation défensive des instructions « peut être contournée via des attaques par injection »[3].

La décision qui en découle s’énonce simplement. Pour chaque règle écrite dans les instructions de l’agent (« ne jamais rembourser plus de… », « ne pas écrire en production »), nommez le contrôle extérieur au modèle qui l’applique. S’il n’existe pas, la règle est un souhait.

Le troisième principe est le plus directement utilisable. Il demande de définir des critères de criticité, puis de ranger chaque action possible de l’agent, selon sa finalité, dans une catégorie[1].

L’approbation humaine est recommandée pour quatre familles d’actions : les actions critiques, notamment dans les systèmes d’IA à haut risque au sens de l’article 6 du règlement européen sur l’IA ; les accès à des données sensibles ; les modifications d’identité ou de droits ; les déploiements en production. Deux conditions l’accompagnent. Le mécanisme d’approbation reste « hors de portée du système agentique » : un agent ne valide pas sa propre demande. Et l’approbateur voit « l’action exacte, son objectif et ses effets attendus », l’outil n’exécutant « que l’action approuvée ».

Ce dernier point touche directement les écrans de validation. Un bouton « Approuver » posé sur une intention (« répondre au client ») ne suffit pas : l’accord doit porter sur le destinataire, le contenu ou le montant qui partiront réellement. Nous détaillons ce mécanisme, et les droits que les agents accumulent en pratique, dans « Vos agents ont-ils plus de droits que vos administrateurs ? ».

Le deuxième principe complète le classement. Il demande d’inventorier les accès, les ressources et les capacités de l’agent, de les justifier « au regard du strict besoin métier », et de n’élargir son autonomie qu’après avoir vérifié l’efficacité des mesures de sécurité et des procédures de gestion d’incidents.

Le cinquième principe dit où placer le contrôle : lorsque c’est réalisable, un filtrage déterministe et indépendant de l’agent, « en amont de chaque outil ou ressource », sans possibilité de contournement ou de modification par l’agent[1]. Ce filtre authentifie le demandeur et vérifie ses droits, l’action et ses paramètres effectifs, sa cible et les règles métier, « selon une politique inaltérable par le modèle ». Puis : « Par défaut, refuser l’action. »

La question n’est plus « l’agent a-t-il compris qu’il ne devait pas ? » mais « le service a-t-il refusé ? ». Le guide demande aussi de vérifier qu’un enchaînement d’actions autorisées une à une ne produit pas d’effet interdit, et de n’accorder aux agents « aucune confiance ni aucun privilège implicites ».

Le quatrième principe cloisonne. Il recommande des identités, des secrets et des connecteurs dédiés à chaque environnement (développement, évaluation, production), des espaces mémoire séparés par organisation cliente et par environnement, et des communications externes qui passent exclusivement par des interfaces maîtrisées, authentifiées, chiffrées et filtrées par destination, protocole et type de données[1]. Il rappelle enfin que « toute donnée transmise à un modèle hébergé peut être accessible à son fournisseur ».

Des éditeurs le disent aussi. Supabase recommande de ne connecter son serveur MCP (le connecteur qui donne à un agent l’accès à la base) à un projet de production que si la tâche exige des éléments de production, en le limitant à ce projet et en lecture seule[4].

Les principes six et sept traitent du moment où le reste a échoué. Les secrets doivent rester « hors du contexte du modèle, des mémoires et des journaux », confiés à un coffre-fort ou à un proxy ; l’agent reçoit des jetons à durée de validité courte, limités aux droits strictement nécessaires[1]. Les bonnes pratiques de sécurité du protocole MCP vont dans le même sens : un serveur MCP ne doit accepter aucun jeton qui n’a pas été émis pour lui, et les droits démarrent au minimum avant d’être élargis au cas par cas[5].

Le guide demande aussi un arrêt d’urgence qui révoque les accès, un mode dégradé qui n’affaiblit pas les contrôles et n’élargit pas les droits, et des restaurations testées. Il y ajoute un contrôle précis : vérifier qu’après une restauration, une action déjà exécutée avec un effet externe (un virement, un e-mail) n’est pas rejouée.

Les journaux, enfin, doivent rester « hors de portée des modifications de l’agent », pour qu’on puisse reconstituer après un incident la séquence complète : demande, autorisation, action, résultat. Si l’agent peut effacer la trace de ce qu’il a fait, il n’y a pas de trace. Le septième principe y joint un inventaire des composants, des instructions système et des dépendances, des tests avant déploiement puis réguliers, et un référentiel des responsables mis à jour après chaque changement ou incident.

Le premier principe se joue avant tout cela : une analyse de risque dès la conception, actualisée à chaque évolution, un responsable humain pour chaque mesure, et une mise en service bloquée « tant qu’un risque reste inacceptable ». Pour un agent acheté, le guide demande que le cahier des charges impose les exigences de sécurité issues de cette analyse.

Le guide ne fixe aucun seuil et ne promet pas qu’un agent bien configuré est sûr. Il ne nomme pas non plus les assistants d’automatisation installés sur les postes de travail. Le bulletin du CERT-FR d’avril le fait : selon lui, les assistants personnels autonomes comme OpenClaw ne doivent pas être déployés sur les postes « tant que le produit n’est pas stabilisé et éprouvé du point de vue de la sécurité »[3].

Pour un premier passage, prenez un seul agent, celui qui a le plus de droits ou qui lit le plus de contenu venu de l’extérieur, et vérifiez ces points avec son responsable.

Rien dans cette liste ne demande d’acheter un outil. Elle demande de savoir, pour chaque agent, qui décide, à quel endroit, et ce qui reste écrit après coup.