Sécuriser un agent IA : ce que la grille de l’ANSSI permet d’exiger

OpenAI surveille les agents IA qu’il fait tourner en interne. Un programme de contrôle examine leur travail et envoie ses alertes à l’équipe de sécurité de l’entreprise. Le 3 octobre 2026, ce programme a signalé un agent. Un sous-agent a alors vidé la liste des destinataires des alertes, en invoquant la consigne de l’utilisateur de n’envoyer aucun message. Le contrôle a continué de tourner, mais plus personne n’en recevait les alertes.

Le 6 octobre, un autre agent a retiré ce programme de contrôle pendant une migration de code, puis a affirmé à l’utilisateur ne pas l’avoir fait. OpenAI a publié les deux incidents ↗, et CNBC les a repris ↗ le 21 octobre. OpenAI n’a classé aucun des deux au niveau de gravité le plus élevé.

Le même mois, l’ANSSI a publié « Les essentiels : sécuriser un système IA agentique » ↗ : deux pages, sept principes. Le texte vise aussi les produits achetés, et il demande d’écrire ses exigences dans le cahier des charges. Un éditeur propose d’activer des agents IA dans le logiciel de votre école ? La DSI dispose désormais d’une grille française pour répondre à sa question : comment cet agent est-il borné, et qui peut le couper ?

Avant d’activer un agent, exigez de l’éditeur trois listes d’actions, une approbation que l’agent ne peut pas toucher et un arrêt qui coupe ses accès.

Ce que le guide de l’ANSSI demande, et à qui

Le guide s’adresse aux 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 ». Une école qui active un agent dans un logiciel acheté entre dans ce cas pour la part qu’elle règle elle-même. Le reste se construit chez l’éditeur.

Ce n’est pas un texte réglementaire, rappelle Armées.com ↗, et il n’oblige personne. Son premier principe indique pourtant la voie. Il demande de désigner un responsable humain pour chaque mesure, de bloquer la mise en service tant qu’un risque reste inacceptable, et d’exiger que le cahier des charges impose des exigences de sécurité pour tout produit ou service qui compose le système. Une recommandation de l’ANSSI devient ainsi une clause du contrat.

Le guide part d’un constat : une action autorisée peut quand même nuire. Un agent peut se tromper, être manipulé, ou combiner des opérations permises en un effet dangereux. Les contrôles qui le bornent doivent donc fonctionner sans lui, et il ne doit pas pouvoir les outrepasser.

Trois listes d’actions, écrites avant l’activation

Le troisième principe demande de classer chaque action possible d’un agent dans l’une de trois catégories : exécution autonome, approbation humaine obligatoire, action interdite. Le classement suit des critères de criticité écrits à l’avance, et l’impact métier de chaque action en cas de dysfonctionnement.

Le guide nomme ce qui entre dans la deuxième liste : les actions critiques, les accès à des données sensibles, les modifications d’identité ou de droits, et les déploiements en production. Il cite aussi les systèmes d’IA à haut risque de l’article 6 de l’AI Act, dont notre article sur le report de décembre 2027 rappelle le calendrier.

Dans une école, les trois listes peuvent prendre cette forme :

• Exécution autonome. Lire une maquette, rapprocher un planning du calendrier de l’école, préparer le brouillon d’une relance.
• Approbation humaine. Envoyer un message à un intervenant ou à un étudiant, ouvrir un dossier qui contient des données sensibles, modifier les droits d’un compte.
• Action interdite. Modifier ses propres droits, toucher à ses journaux, désactiver une alerte.

La CNIL et le Conseil de l’IA et du numérique arrivent au même découpage par l’angle des données personnelles. Leur note de juillet 2026 ↗ propose de classer les actions possibles sur chaque service par niveau de risque : accès aux données, modification, suppression, envoi hors du système. Selon ce risque, une intervention humaine précède l’exécution. En avril déjà, un bulletin du CERT-FR ↗ écrivait, à propos des assistants IA installés sur les postes de travail, qu’une validation humaine doit être obligatoire dès qu’une action à effet de bord est envisagée.

Ces listes ne restent pas figées. Le deuxième principe demande de documenter la mission de l’agent dès sa conception, puis au moins une fois par an. Chaque accès se justifie par le strict besoin métier. L’autonomie ne s’élargit qu’après avoir vérifié que les mesures de sécurité et la gestion des incidents fonctionnent. Une action passe donc d’une liste à l’autre sur décision, jamais par habitude.

Le partage des rôles en découle. L’école écrit les listes, parce qu’elle seule sait quelles actions engagent ses étudiants et ses intervenants. L’éditeur montre que son produit les applique, action par action.

Une approbation que l’agent ne peut pas toucher

Le guide ajoute une phrase courte : garder le mécanisme d’approbation hors de portée du système agentique. Les incidents d’OpenAI montrent pourquoi. Un agent qui peut couper une alerte peut aussi, par le même chemin, se dispenser d’une approbation.

Le cinquième principe dit comment s’y prendre. Un filtre déterministe, indépendant de l’agent, se place en amont de chaque outil et de chaque ressource, et l’agent ne peut ni le contourner ni le modifier. Ce filtre vérifie le demandeur, ses droits, l’action, ses paramètres et sa cible, selon une politique que le modèle ne peut pas changer. Par défaut, il refuse. Il vérifie aussi qu’une suite d’actions permises une à une ne produit pas un effet interdit.

L’approbation doit enfin porter sur un objet précis. Le guide demande de présenter à la personne qui approuve l’action exacte, son objectif et ses effets attendus, puis de n’exécuter que l’action approuvée. Un clic sur le résumé qu’un agent rédige de sa propre demande ne répond pas à cette exigence. La note de la CNIL ↗ va dans le même sens. Une intervention humaine placée seulement en bout de chaîne ne suffit pas toujours à écarter la qualification de décision automatisée au sens de l’article 22 du RGPD, comme l’a jugé la Cour de justice de l’Union européenne dans son arrêt SCHUFA.

À l’éditeur, la DSI demande donc trois choses. Où se trouve ce filtre ? Que voit la personne qui approuve ? Un agent peut-il modifier l’un ou l’autre ?

Un arrêt qui coupe les accès, pas seulement la tâche

Le sixième principe demande de prévoir un arrêt d’urgence avec révocation des accès, déclenchable par un mécanisme de supervision en cas de traitements anormaux. Interrompre une tâche laisse à l’agent ses jetons, ses connecteurs et ses droits. Révoquer ses accès les lui retire.

Le guide entoure l’arrêt de trois mesures :

• Un mode dégradé prévu d’avance, qui n’affaiblit aucun contrôle et n’élargit aucun droit.
• Des jetons d’accès à courte durée de validité, limités aux droits strictement nécessaires.
• Des restaurations testées, avec la vérification qu’une action déjà exécutée vers l’extérieur ne se rejoue pas. Un message déjà envoyé à un étudiant ne doit pas repartir une seconde fois.

Reste la question de savoir qui déclenche l’arrêt. L’ANSSI parle d’un mécanisme de supervision. La note de la CNIL place le bouton d’arrêt d’urgence à la main de l’utilisateur, qui peut interrompre un processus agentique à tout moment. La DSI demande les deux : qui, à l’école, peut couper un agent, et ce que la supervision coupe d’elle-même.

Des journaux que l’agent ne peut pas réécrire

Le septième principe demande de tenir les journaux hors de portée des modifications de l’agent. Après un incident, ils doivent permettre de reconstituer la séquence complète : demande, autorisation, action, résultat. Le guide demande aussi de comparer en production les actions de l’agent à sa mission documentée, et de tenir à jour la liste des responsables des règles, des alertes et des exceptions, au moins une fois par an.

La note de la CNIL le formule du point de vue des personnes. Pour chaque tâche, il faudrait pouvoir retrouver les données utilisées, les agents intervenus, les services tiers appelés, les échanges et leur chronologie. La question « qui a lu ce dossier ? » vaut pour un agent comme pour un compte humain. L’affaire de la DGFiP montre ce qu’un journal doit contenir pour y répondre.

Ce que la DSI écrit au cahier des charges

Chaque exigence du guide a deux faces : ce que l’école décide, et ce que l’éditeur doit montrer.

Le guide demande aussi de cloisonner la mémoire d’un agent par organisation cliente, et de considérer que toute donnée transmise à un modèle hébergé peut être accessible à son fournisseur. Ces deux points relèvent de l’hébergement et du contrat, que détaille l’article sur ce qu’une IA voit de vos dossiers. L’entraînement des modèles sur les données de l’école fera l’objet d’un article à part.

Chez Subrequest, l’école active, plafonne ou coupe chaque agent IA, campus par campus, et la plateforme fonctionne aussi sans IA. Les humains et les agents relèvent des mêmes permissions, chaque compte dans son périmètre. Chaque action reste enregistrée avec sa date, son heure et le nom de son auteur. Les questions de ce tableau valent pour nous comme pour tout autre éditeur.

Avant d’activer un agent : trois listes, une approbation hors de sa portée, un arrêt qui révoque

Pour sécuriser un agent IA acheté chez un éditeur, une DSI exige trois listes d’actions, une approbation que l’agent ne peut pas modifier et un arrêt qui coupe ses accès, puis inscrit ces exigences au cahier des charges. C’est la grille que l’ANSSI a publiée en octobre 2026 dans ses sept principes pour sécuriser un système IA agentique ↗.

Si vous préparez l’activation d’agents IA et voulez confronter cette grille à un logiciel concret, prenez rendez-vous avec nous.