RBAC et logs restent nécessaires, mais ils ne suffisent plus, car un agent peut causer un dommage avec des droits parfaitement valides. Au 2 novembre 2026, le repère français le plus précis pour y répondre est le document de l’ANSSI publié en octobre : contrôler les actions hors du modèle, cloisonner l’exécution et prévoir l’arrêt d’urgence.

Ce que le RBAC et les logs ne voient pas

Les Essentiels de l’ANSSI sur l’IA agentique (V1.0, octobre 2026) posent le problème dès la première page : « une action autorisée peut être dommageable : un agent peut se tromper, être manipulé ou combiner dangereusement des opérations permises. » Ce texte ne rejette ni les droits d’accès ni les journaux. Il demande des accès maîtrisés et des journaux que l’agent ne peut pas modifier.

Trois limites apparaissent en pratique :

  • Un rôle dit ce qui est permis, pas si l’usage est sûr. Le Top 10 OWASP des applications agentiques, référentiel communautaire daté de décembre 2025, classe ce cas en ASI02 : l’agent reste dans ses droits, mais supprime des données utiles, multiplie les appels à une API coûteuse ou exfiltre des informations.
  • Un agent sans identité propre échappe à l’attribution. L’ASI03 explique que le vrai moindre privilège devient alors impossible à faire respecter. Le NIST travaille sur le même sujet dans un document de réflexion publié le 5 février 2026.
  • Un prompt de sécurité n’est pas un contrôle. Le CERT-FR écrit, le 13 avril 2026, que « si la formulation défensive des prompts peut contribuer à réduire les risques, elle peut être contournée via des attaques par injection ».

Ce que demandent les repères

L’ANSSI formule sept principes. Trois changent directement l’architecture.

Autoriser hors du modèle. Le document demande de « Placer, lorsque cela est réalisable, un mécanisme de 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. » Ce filtre vérifie le demandeur, l’action, ses paramètres effectifs, sa cible et les règles métier, puis refuse par défaut. Il vérifie aussi qu’un enchaînement d’actions autorisées une à une ne produit pas d’effet interdit.

Classer les actions. Chaque action relève d’une catégorie : « exécution autonome, approbation humaine obligatoire et action interdite. » L’approbation reste hors de portée de l’agent et présente à la personne l’action exacte, son objectif et ses effets attendus. Une validation de routine, sans ces informations, protège peu : c’est notre analyse.

Limiter l’impact. Secrets hors du contexte du modèle, jetons courts et limités, exécution isolée, identités et connecteurs dédiés à chaque environnement, journaux hors de portée de l’agent et arrêt d’urgence avec révocation des accès.

Risque Mesure Source
Action autorisée mais dommageable Filtre déterministe, refus par défaut, contrôle des enchaînements ANSSI, oct. 2026 ; OWASP ASI02, déc. 2025
Injection de prompt, détournement d’objectif Entrées non fiables, moindre privilège, approbation des actions à fort impact OWASP ASI01 ; ANSSI
Privilèges hérités, pas d’identité propre Identité par agent, jetons courts limités à la tâche OWASP ASI03 ; ANSSI
Fuite de secrets Coffre-fort ou proxy, secrets hors du contexte et des journaux ANSSI
Chaîne d’approvisionnement : OAuth, skills, plugins Inventaire, provenance, revue des autorisations, exécution isolée ANSSI ; Vercel, 2026 ; TrendAI, fév. 2026
Assistant autonome sur un poste de travail Pas de déploiement sur les postes, essais en bac à sable sans données sensibles CERT-FR, avr. 2026
Mémoire persistante et données personnelles Mémoire cloisonnée, sandboxing, arrêt à la main de l’utilisateur CNIL/CIANum, juil. 2026
Journaux modifiables Séquence demande, autorisation, action et résultat, hors de portée de l’agent ANSSI

Ce que ces textes imposent, et ce qu’ils n’imposent pas

Ces repères n’ont pas tous la même portée, et il ne faut pas les étendre.

  • Les Essentiels de l’ANSSI sont des recommandations, sans label ni certification. Ils servent de repère d’état de l’art.
  • Le CERT-FR ne proscrit pas tous les agents. Sa phrase vise « les assistants personnels autonomes tels qu’OpenClaw » sur les postes de travail, « tant que le produit n’est pas stabilisé et éprouvé du point de vue de la sécurité ». Il ajoute que les produits d’automatisation de tâches bureautiques par IA agentique, pas encore éprouvés, ne doivent pas être déployés en production. Un agent serveur relève plutôt des Essentiels, qui couvrent aussi les produits sur étagère dont l’organisation maîtrise la configuration et les connecteurs.
  • La note CNIL/CIANum est exploratoire. Elle évoque le cloisonnement de la mémoire, les environnements isolés et un bouton d’arrêt. Elle présente la validation humaine des décisions critiques comme une trajectoire juridique possible, pas comme le droit en vigueur.

Pour un système à haut risque, la date et les obligations relèvent du règlement européen : voir notre article sur l’AI Act après l’Omnibus.

Ce que montrent les incidents de 2026

Vercel, avril 2026. Selon le bulletin de l’entreprise, dont la dernière mise à jour date du 16 octobre 2026, l’incident part de la compromission de Context.ai, un outil d’IA tiers utilisé par un employé. Son application OAuth Google Workspace a permis de reprendre le compte de cet employé, puis d’énumérer et de déchiffrer des variables d’environnement non marquées comme sensibles. Le bulletin ne décrit ni injection de prompt ni attaque contre un agent. Notre lecture : le risque vient ici de la chaîne d’approvisionnement des outils d’IA.

Skills malveillants, février 2026. TrendAI, éditeur de sécurité, décrit le 23 février des skills OpenClaw qui poussent à installer un faux outil en ligne de commande et diffusent un voleur d’informations pour macOS. Il recommande de tester les skills non validés en environnement contrôlé et d’isoler l’exécution.

Fichiers de configuration, février 2026. Check Point Research a publié le 25 février des failles de Claude Code déclenchées par des fichiers de projet. L’éditeur les avait corrigées entre août et décembre 2025 : elles illustrent un type de risque, pas un état actuel. La leçon vaut pour tout outil : relire la configuration avec la même rigueur que le code.

Les actions à mener maintenant

  1. Classez chaque action de vos agents en trois catégories, en commençant par les écritures, les envois externes, les paiements et les changements de droits.
  2. Placez l’autorisation dans une couche déterministe en amont de chaque outil, avec refus par défaut, puis testez les enchaînements.
  3. Donnez à chaque agent sa propre identité et des jetons courts limités à la tâche. Sortez les secrets du contexte du modèle.
  4. Séparez développement, évaluation et production, et isolez l’exécution des agents et des outils.
  5. Tenez un inventaire des prompts système, connecteurs, skills et applications OAuth. Revoyez régulièrement les autorisations accordées aux outils d’IA.
  6. Journalisez hors de portée de l’agent la séquence demande, autorisation, action et résultat, puis comparez les actions à la mission documentée.
  7. Testez l’arrêt d’urgence avec révocation des accès et mode dégradé.
  8. N’installez pas d’assistant autonome du type OpenClaw sur les postes de travail, et ne mettez pas en production les produits d’automatisation bureautique visés par le CERT-FR.

Sources

État consulté le 2 novembre 2026.