La sécurité de l’IA agentique pose une question que la sécurité applicative n’avait jamais eu à traiter : que faire d’un système qui planifie, garde une mémoire, appelle des outils et agit avec une autorité déléguée ? Presque tous les guides viennent d’éditeurs de sécurité et s’arrêtent à la menace. La liste de référence, l’OWASP Top 10 for Agentic Applications, compte 57 pages et ne cite aucune réglementation. Ce guide relit les dix mêmes risques comme le ferait un auditeur ou une autorité de surveillance du marché : quelle obligation chaque risque touche, quelle trace prouve que vous l’avez traité, et quelles échéances courent déjà.
L’essentiel
- Un agent ne distingue pas fiablement une instruction d’un contenu lu : le point de contrôle est ce qu’il peut faire, pas ce qu’on lui dit.
- L’OWASP Top 10 for Agentic Applications (9 décembre 2025) recense dix risques, ASI01 à ASI10, et 86 mesures numérotées selon notre décompte.
- Ses 57 pages ne mentionnent ni le règlement sur l’IA ni l’ISO/IEC 42001 : la lecture juridique reste à construire.
- Pour la Commission, les agents sont des systèmes d’IA, pas une catégorie à part ; son projet de lignes directrices sur le haut risque (19 mai 2026) évalue un système agentique comme un tout.
- Le signalement du règlement sur la cyberrésilience s’applique depuis le 11 septembre 2026, l’article 50 depuis le 2 août 2026 ; le haut risque (annexe III) arrive le 2 décembre 2027.
Qu’est-ce que la sécurité de l’IA agentique ?
La sécurité de l’IA agentique est la discipline qui consiste à maintenir dans le périmètre voulu par leur propriétaire des systèmes qui planifient, mémorisent, appellent des outils et agissent par délégation, et à pouvoir le prouver. L’OWASP prend pour canevas quatre capacités : la planification et le raisonnement, la mémoire, l’usage d’outils, l’action. La différence avec la sécurité des applications bâties sur un modèle de langage tient en une phrase : dans un assistant conversationnel, le modèle est un composant dont on filtre les entrées et les sorties ; dans un agent, le modèle est un acteur. Voir nos guides sur la sécurité de l’IA et sur les agents IA autonomes.
Pourquoi les agents cassent les hypothèses de la sécurité applicative
- Le code et les données ne sont plus séparables. L’OWASP l’écrit : les agents et le modèle sous-jacent ne savent pas distinguer de manière fiable une instruction d’un contenu associé.
- L’identité qui agit n’est pas celle qui a demandé. Avec les chaînes de délégation et les identifiants hérités, un agent peut agir au-delà de ce que le demandeur aurait pu faire lui-même.
- Une faute unique persiste et se propage. Elle s’installe dans la mémoire, puis passe aux autres agents.
La lettre des responsables du projet OWASP en tire deux principes. Le premier, Least Agency (moindre autonomie), demande d’éviter l’autonomie inutile : déployer un comportement agentique là où il n’est pas nécessaire élargit la surface d’attaque sans rien apporter. Le second fait de l’observabilité une exigence non négociable : savoir ce que font les agents, pourquoi, et quels outils ils invoquent. Pour un test en une ligne, retenez la « lethal trifecta » de Simon Willison : données privées, contenu non fiable, communication vers l’extérieur. L’agent qui réunit les trois passe en premier.
La liste de référence de la sécurité de l’IA agentique : l’OWASP Top 10 for Agentic Applications
L’OWASP Top 10 for Agentic Applications a été publié le 9 décembre 2025 par l’OWASP GenAI Security Project, au sein de son Agentic Security Initiative : 57 pages, une licence CC BY-SA 4.0, plus de 100 contributeurs. Son objet : l’IA agentique, pas l’IA générative. Chaque entrée suit le même plan : description, exemples courants, scénarios d’attaque, mesures de prévention et d’atténuation. Selon notre décompte, l’ensemble représente 86 mesures numérotées (entre 7 et 10 par entrée) et 61 scénarios d’attaque. <table header-row= »true »> <tr> <td>ID</td> <td>Entrée</td> <td>Ce qui dérape</td> <td>Premier contrôle cité par l’OWASP</td> </tr> <tr> <td>ASI01</td> <td>Agent Goal Hijack (détournement d’objectif)</td> <td>Un attaquant réoriente les objectifs ou les décisions de l’agent par des prompts, des sorties d’outils, des documents ou des messages falsifiés</td> <td>Toute entrée en langage naturel est non fiable ; approbation humaine pour changer d’objectif</td> </tr> <tr> <td>ASI02</td> <td>Tool Misuse and Exploitation (usage détourné des outils)</td> <td>L’agent emploie un outil légitime de façon dangereuse : exfiltration, action destructrice, appels en chaîne</td> <td>Moindre autonomie et moindre privilège par outil : périmètres, limites de débit, listes d’autorisation en sortie</td> </tr> <tr> <td>ASI03</td> <td>Identity and Privilege Abuse (abus d’identité et de privilèges)</td> <td>Délégations et identifiants hérités ou mis en cache laissent l’agent dépasser les droits du demandeur</td> <td>Permissions limitées à la tâche et dans le temps ; autorisation action par action</td> </tr> <tr> <td>ASI04</td> <td>Agentic Supply Chain Vulnerabilities (chaîne d’approvisionnement)</td> <td>Un outil tiers, un plug-in, un serveur MCP, un modèle, un prompt ou un agent est malveillant ou altéré</td> <td>Provenance, SBOM et AIBOM, manifestes signés, liste d’autorisation et épinglage</td> </tr> <tr> <td>ASI05</td> <td>Unexpected Code Execution (exécution de code inattendue)</td> <td>Du code généré ou une entrée d’outil devient une exécution de commandes sur un hôte</td> <td>Bac à sable, aucun chemin direct vers la production, approbation des exécutions à privilèges</td> </tr> <tr> <td>ASI06</td> <td>Memory and Context Poisoning (empoisonnement de la mémoire)</td> <td>Le contexte stocké (résumés, embeddings, bases RAG) reçoit un contenu faux ou malveillant qui persiste entre sessions</td> <td>Validation des écritures, mémoire segmentée, provenance, instantanés et retour arrière</td> </tr> <tr> <td>ASI07</td> <td>Insecure Inter-Agent Communication (échanges non sécurisés entre agents)</td> <td>Des messages entre agents sont usurpés, rejoués ou modifiés</td> <td>Authentification mutuelle, messages signés, protocole épinglé, registres attestés</td> </tr> <tr> <td>ASI08</td> <td>Cascading Failures (défaillances en cascade)</td> <td>Une faute se propage d’agents en outils jusqu’au dommage systémique</td> <td>Isolation et frontières de confiance, disjoncteurs, contrôle indépendant des politiques, journaux à altération détectable</td> </tr> <tr> <td>ASI09</td> <td>Human-Agent Trust Exploitation (confiance abusée)</td> <td>Les personnes font trop confiance à un agent éloquent et approuvent des actions nuisibles</td> <td>Confirmations explicites, aperçu séparé de l’effet, résumés du risque en langage clair</td> </tr> <tr> <td>ASI10</td> <td>Rogue Agents (agents hors de contrôle)</td> <td>Un agent compromis ou mal aligné sort de son périmètre alors que chaque action paraît légitime</td> <td>Journaux d’audit signés, surveillance comportementale, arrêt d’urgence et révocation, quarantaine et réintégration</td> </tr> </table> Deux constats. D’abord, la journalisation ou la surveillance figure parmi les mesures numérotées dans neuf entrées sur dix, l’approbation humaine dans sept. Lue en travers, la liste est un cahier des charges pour vos journaux et vos règles d’approbation. Ensuite, les identifiants renvoient au Top 10 des applications LLM (annexe A), au Top 10 des identités non humaines (annexe C), à CycloneDX et à l’AIBOM (annexe B). Ils ne renvoient à aucune loi.
Ce que montre le registre des incidents
Le Top 10 est livré avec un registre d’exploits et d’incidents (annexe D), mis à jour chaque semaine sur GitHub : environ deux douzaines d’incidents publics datés de février à octobre 2025, le plus souvent rattachés à Tool Misuse, Agent Goal Hijack et Unexpected Code Execution.
- Février 2025 : injection de prompt dans ChatGPT Operator par un contenu web.
- Avril 2025 : attaque « agent-in-the-middle » au moyen d’une fausse carte d’agent dans un annuaire A2A ouvert.
- Juillet 2025 : des agents Copilot Studio publics par défaut et dépourvus d’authentification.
- Septembre 2025 : ForcedLeak dans Salesforce Agentforce, par injection indirecte de prompt, et le premier serveur MCP malveillant repéré en circulation sur npm, qui usurpait postmark-mcp.
Le rapport de l’OWASP State of Agentic AI Security and Governance (version 2.01, 1er juin 2026), résumé par Help Net Security le 11 juin 2026, marque un basculement : l’édition 2025 cataloguait des menaces plausibles, l’édition 2026 catalogue des CVE, des avis de sécurité d’éditeurs et des rapports de compromission. Sur 53 projets agentiques suivis, 28 sont des agents de programmation. Les avis les plus nombreux concernent n8n (57), Claude Code (22), AutoGPT (15), Dify (13) et Roo-Code (11). En mars 2026, un paquet LiteLLM piégé a été publié sur PyPI : environ 47 000 téléchargements en trois heures, pour une passerelle qu’utilisent plusieurs frameworks d’agents. Pour la sécurité de l’IA agentique, deux leçons. Le point d’entrée est le plus souvent banal : un paquet, une page web, un ticket, un réglage par défaut. L’ampleur du dommage, elle, dépend de ce que l’agent avait le droit de faire. D’où l’intérêt du red teaming de l’IA et de MITRE ATLAS.
Ce que les guides de sécurité de l’IA agentique laissent de côté : le droit
Nous avons passé le PDF du Top 10 en recherche plein texte : aucune mention du règlement sur l’IA (AI Act), de l’ISO/IEC 42001 ni d’une quelconque réglementation. Pour un document de sécurité, ce n’est pas un défaut. Pour celui qui doit répondre de la sécurité de l’IA agentique devant une autorité, c’est un vide. Depuis, le GenAI Security Industry Framework Crosswalk, publié par l’OWASP le 1er septembre 2026, relie ses risques d’IA générative à 25 référentiels, dont l’AI Act. Index utile, mais correspondance communautaire, pas lecture juridique. Que dit la Commission ? Que les agents ne forment pas une catégorie distincte : les définitions du système d’IA (article 3, point 1) et du modèle d’IA à usage général (article 3, point 63) les couvrent. Son projet de lignes directrices sur la classification des systèmes d’IA à haut risque, mis en consultation le 19 mai 2026, va plus loin. D’après les commentaires de cabinets d’avocats, un système composé de plusieurs éléments en interaction, systèmes agentiques compris, s’évalue comme un tout, et la dérogation de l’article 6, paragraphe 3, ne se revendique pas module par module. La version définitive est attendue. Le tableau suivant est notre lecture, pas une correspondance établie par l’OWASP ou par la Commission. <table header-row= »true »> <tr> <td>Entrée</td> <td>Point d’accroche dans l’AI Act</td> <td>Preuves que demande un auditeur</td> </tr> <tr> <td>ASI01</td> <td>Art. 15(5), tentatives de modifier l’utilisation, les sorties ou la performance ; art. 9, gestion des risques</td> <td>Inventaire des canaux d’entrée non fiables ; prompt système versionné ; rapport de test de détournement d’objectif</td> </tr> <tr> <td>ASI02</td> <td>Art. 14, contrôle humain ; art. 26(1), utilisation conforme à la notice</td> <td>Registre des outils avec périmètres, limites de débit et de sortie ; règle d’approbation des actions destructrices ; journal immuable des appels d’outils</td> </tr> <tr> <td>ASI03</td> <td>Art. 15(5) ; RGPD, art. 32</td> <td>Une identité par agent ; identifiants courts et restreints ; revue des chaînes de délégation</td> </tr> <tr> <td>ASI04</td> <td>Art. 25, chaîne de valeur ; règlement sur la cyberrésilience, annexe I</td> <td>AIBOM ou SBOM ; outils et serveurs MCP signés et épinglés ; évaluations des fournisseurs</td> </tr> <tr> <td>ASI05</td> <td>Art. 15(4) et (5) ; règlement sur la cyberrésilience, annexe I</td> <td>Configuration du bac à sable ; liste versionnée des exécutions automatiques autorisées ; journaux d’analyse</td> </tr> <tr> <td>ASI06</td> <td>Art. 10, gouvernance des données ; art. 15(5), empoisonnement des données</td> <td>Règle de validation des écritures en mémoire ; traces de provenance ; test de retour arrière ; règle de conservation</td> </tr> <tr> <td>ASI07</td> <td>Art. 15(5) ; art. 12, enregistrement</td> <td>Configuration de l’authentification mutuelle ; messages signés ; registre des agents ; politique de version de protocole</td> </tr> <tr> <td>ASI08</td> <td>Art. 15(4), résilience aux erreurs et aux défaillances ; art. 72, surveillance après commercialisation</td> <td>Limites du rayon d’impact ; résultats des tests de disjoncteurs ; traces des tests de rejeu</td> </tr> <tr> <td>ASI09</td> <td>Art. 14(4)(b), biais d’automatisation ; art. 50(1)</td> <td>Conception des confirmations pour les actions risquées ; canal de signalement des utilisateurs ; registres de formation à la supervision</td> </tr> <tr> <td>ASI10</td> <td>Art. 14(4)(e), arrêt ; art. 72 ; art. 73, incidents graves</td> <td>Exercice d’arrêt d’urgence et de révocation ; référence comportementale ; procédure de quarantaine et de réintégration</td> </tr> </table> Reste l’ISO/IEC 42001. Plusieurs domaines de contrôle de son annexe A s’appliquent aux agents : le cycle de vie du système d’IA (exploitation et surveillance, journaux d’événements), les relations avec les tiers et les clients, l’utilisation des systèmes d’IA, les responsabilités. Un auditeur de certification demandera comment les risques propres aux agents ont été identifiés, et ce qui a été décidé pour chacun.
Quels textes rendent exigibles les preuves de sécurité de l’IA agentique
Une liste de l’OWASP n’oblige personne. Ces textes, si.
- AI Act, articles 9, 12, 14 et 15 : pour les systèmes à haut risque, gestion des risques, journaux d’événements automatiques, supervision humaine (« contrôle humain » dans le texte officiel) avec la capacité d’interrompre le système par un bouton d’arrêt ou une procédure similaire (article 14, paragraphe 4, point e), et résilience face aux tentatives de tiers non autorisés de modifier l’utilisation, les sorties ou la performance (article 15, paragraphe 5). Annexe III à partir du 2 décembre 2027, annexe I à partir du 2 août 2028, depuis l’omnibus numérique, règlement (UE) 2026/1744.
- AI Act, article 26 : les déployeurs utilisent le système conformément à la notice, confient la supervision à des personnes compétentes, surveillent le fonctionnement et conservent les journaux générés automatiquement au moins six mois.
- AI Act, article 50 : depuis le 2 août 2026, un agent qui interagit directement avec des personnes doit leur faire savoir qu’elles ont affaire à un système d’IA.
- AI Act, article 55 : pour les modèles d’IA à usage général présentant un risque systémique, essais contradictoires et protection de la cybersécurité, depuis le 2 août 2025.
- Règlement sur la cyberrésilience, règlement (UE) 2024/2847 : il vise les produits comportant des éléments numériques, donc la plupart des logiciels commerciaux qui embarquent un agent. Depuis le 11 septembre 2026, les fabricants signalent les vulnérabilités activement exploitées et les incidents graves : alerte précoce sous 24 heures, notification sous 72 heures. Exigences essentielles complètes le 11 décembre 2027.
- RGPD, article 32 : sécurité du traitement dès que l’agent touche à des données personnelles.
- NIS2 et DORA : entités essentielles et importantes, entités financières ; la gestion des risques liés aux TIC et le signalement des incidents sont déjà dus. DORA s’applique depuis le 17 janvier 2025.
S’y ajoutent les délais de l’article 73 de l’AI Act pour le signalement des incidents graves des systèmes à haut risque : 15 jours, 2 jours pour une infraction de grande ampleur ou une perturbation d’infrastructure critique, 10 jours en cas de décès. Un incident d’agent peut donc lancer trois horloges à la fois : règlement sur la cyberrésilience, RGPD, AI Act. En France, la sécurité de l’IA agentique a deux interlocuteurs : l’ANSSI, côté CSIRT, pour les signalements du règlement sur la cyberrésilience, et la CNIL pour l’article 32 du RGPD. L’ANSSI a cosigné avec le BSI allemand les Design Principles for LLM-based Systems with Zero Trust : six principes, dont l’authentification et l’autorisation, le bac à sable et la surveillance.
De la sécurité de l’IA agentique à la preuve : une méthode en sept étapes
- Inventoriez chaque agent. Propriétaire, finalité, modèle, outils et leurs périmètres, mémoires, identités et identifiants, autres agents avec lesquels il échange, systèmes qu’il peut modifier. C’est la logique de l’inventaire des systèmes d’IA, tenu dans un registre.
- Appliquez le principe Least Agency. Pour chaque agent, consignez pourquoi l’autonomie est nécessaire et ce qu’il peut faire sans approbation, puis retirez les outils dont il n’a pas besoin. Un refus consigné est une preuve.
- Donnez à chaque agent sa propre identité. Pas de compte de service partagé, des identifiants à durée courte et limités à la tâche, des permissions liées au sujet, à la ressource, à la finalité et à la durée.
- Écrivez la règle d’approbation. Quelles actions exigent un humain (supprimer, payer, publier, accorder un accès, changer un objectif), qui approuve, et comment la demande s’affiche pour que l’approbation ne devienne pas un réflexe. Voir la supervision humaine.
- Journalisez ce qu’une autorité demandera. L’objectif, le plan, chaque appel d’outil avec ses paramètres, chaque approbation, chaque message entre agents. Le tout horodaté, à altération détectable, et conservé au moins six mois lorsque l’AI Act s’applique.
- Testez avant la mise en service et après chaque changement. Un nouvel outil, une nouvelle version du modèle, un nouveau prompt ou une nouvelle source de mémoire rouvrent ASI01, ASI02 et ASI06. Ajoutez au red teaming un exercice d’arrêt d’urgence et de révocation des identifiants.
- Mettez la chaîne d’approvisionnement et les horloges par écrit. AIBOM ou SBOM, outils et serveurs MCP épinglés et signés, clauses fournisseurs (voir la due diligence des fournisseurs d’IA), et le nom de la personne qui déclare sous 24 ou 72 heures.
Chaque étape laisse une trace ; ensemble, elles forment la déclaration d’applicabilité de votre sécurité de l’IA agentique : dix entrées et, pour chacune, une décision, un contrôle, un responsable, un résultat de test.
Rôles : qui répond de la sécurité de l’IA agentique dans la chaîne de valeur
Un agent est rarement l’œuvre d’un seul acteur : fournisseur de modèle, framework, éditeurs d’outils et de serveurs MCP, intégrateur, organisation qui déploie. L’article 25 de l’AI Act tranche pour le haut risque : celui qui appose son nom sur un système, le modifie de façon substantielle ou en change la destination devient fournisseur. Assembler un agent à partir d’un modèle à usage général et d’outils peut ainsi faire de l’intégrateur le fournisseur d’un système d’IA. L’article AI Agents Under EU Law, paru sur arXiv en 2026, propose une architecture de conformité en douze étapes. Il conclut que la tâche fondatrice du fournisseur est un inventaire exhaustif des actions externes de l’agent, de ses flux de données, des systèmes connectés et des personnes concernées, et que les systèmes agentiques à haut risque dont la dérive comportementale n’est pas traçable ne peuvent pas, à ce jour, satisfaire aux exigences essentielles. Le rapport Ahead of the Curve de The Future Society (juin 2025) parle du « many hands problem » et répartit les obligations entre fournisseurs de modèles, fournisseurs de systèmes et déployeurs. En pratique, trois conséquences pour la sécurité de l’IA agentique :
- Des clauses contractuelles : notification des changements, avis de vulnérabilité, accès aux journaux.
- Un RACI interne entre la sécurité, la fonction de gouvernance de l’IA et le responsable métier (voir la responsabilité en matière d’IA).
- Le suivi de la dérive comme contrôle de conformité, sur le modèle de la dérive du modèle.
Normes en mouvement : que suivre en attendant les normes harmonisées
La sécurité de l’IA agentique n’a pas encore de norme harmonisée, mais les chantiers avancent. Aux États-Unis, le NIST a lancé le 17 février 2026 son AI Agent Standards Initiative, porté par le Center for AI Standards and Innovation (CAISI). Trois piliers : des normes conduites par l’industrie, des protocoles open source, de la recherche sur la sécurité et l’identité des agents. Sa consultation sur la sécurisation des systèmes d’agents s’est close le 9 mars 2026, celle du NCCoE sur l’identité et l’autorisation des agents le 2 avril 2026. D’après des notes de recherche de la Cloud Security Alliance, des surcouches de contrôles SP 800-53 pour les déploiements à un ou plusieurs agents sont en préparation, sans date de publication. Le profil NIST AI 600-1 reste la référence pour l’IA générative. Côté OWASP, deux pièces complètent le Top 10 : le Securing Agentic Applications Guide 1.0 et l’Agent Control Standard, donné au projet en septembre 2026 et tourné vers l’application des règles à l’exécution. Le CLTC de l’université de Berkeley a publié en février 2026 son Agentic AI Risk-Management Standards Profile (version 1.0). Il prolonge le NIST AI RMF et défend une gouvernance proportionnée au degré d’autonomie, plutôt qu’une autonomie binaire. Dans l’Union, les normes harmonisées de l’AI Act étaient encore en préparation au CEN-CENELEC en 2026. Tant qu’aucune n’est citée au Journal officiel, la structure la plus défendable associe une taxonomie publique reconnue et vos propres enregistrements, dans un système de management de type ISO/IEC 42001.
Questions fréquentes
Qu’est-ce que la sécurité de l’IA agentique, en termes simples ? C’est l’ensemble des mesures qui empêchent un agent d’IA de sortir du cadre fixé par celui qui en répond, et qui permettent de le démontrer. Un agent planifie, retient, appelle des outils et agit par délégation. Le sécuriser revient à borner ce qu’il peut faire, à lui donner une identité propre, à soumettre les actions sensibles à une approbation et à tout journaliser. En quoi la sécurité de l’IA agentique diffère-t-elle de la sécurité de l’IA ou des LLM ? La sécurité des LLM protège un modèle vu comme un composant. Avec un agent, le modèle devient un acteur qui détient des identifiants, écrit dans une mémoire et déclenche des actions. Les risques se déplacent vers les outils, les identités, la mémoire et les échanges entre agents. Le Top 10 des agents complète celui des applications LLM sans le remplacer. L’OWASP Top 10 for Agentic Applications est-il obligatoire ? Non. C’est un document communautaire, sans force juridique. Ce qui devient exigible, ce sont les preuves, dès qu’un texte s’applique : journaux et supervision au titre de l’AI Act pour un système à haut risque, signalement des vulnérabilités au titre du règlement sur la cyberrésilience, sécurité du traitement au titre du RGPD. Le Top 10 offre une structure reconnue pour ranger les preuves de votre sécurité de l’IA agentique. Le règlement européen sur l’IA couvre-t-il les agents d’IA ? Oui, en tant que systèmes d’IA : la Commission ne les traite pas comme une catégorie à part. Le classement à haut risque dépend de l’usage, pas de la technologie. L’article 50 impose depuis le 2 août 2026 d’informer les personnes qui interagissent directement avec un agent. Et, d’après les commentaires du projet de lignes directrices du 19 mai 2026, un système agentique s’évalue dans son ensemble. Que signifie Least Agency en pratique pour la sécurité de l’IA agentique ? Le principe demande de justifier l’autonomie avant de l’accorder. Pour chaque agent : écrire pourquoi l’autonomie est nécessaire, lister ce qu’il peut faire sans approbation, retirer les outils dont il n’a pas besoin, réduire les périmètres des autres. La décision de ne pas rendre un processus agentique compte aussi, à condition d’être consignée. L’OWASP le rappelle : l’autonomie superflue élargit la surface d’attaque sans rien apporter. Par quoi commencer pour la sécurité de l’IA agentique ? Par trois gestes, dans cet ordre. D’abord l’inventaire : quels agents tournent, qui en répond, quels outils et quels identifiants ils détiennent. Ensuite le retrait des outils dont un agent n’a pas besoin. Enfin une identité propre par agent, à la place des comptes de service partagés. Tout le reste en dépend : on ne journalise ni ne teste ce qu’on n’a pas recensé.
Conclusion
La communauté de la sécurité a fait sa part : dix risques, 86 mesures, un registre d’incidents qui s’allonge chaque semaine. Ce qu’elle ne dit pas, c’est quel texte s’applique, à quelle date, et ce qu’une autorité demandera à voir. Cette part de la sécurité de l’IA agentique vous revient : l’inventaire, la décision de Least Agency, l’identité, la règle d’approbation, les journaux, les tests, les horloges. Le signalement du règlement sur la cyberrésilience est déjà en vigueur, et décembre 2027 apportera les obligations de haut risque et les exigences complètes pour les produits. AI Sigil enregistre chaque agent dans le registre comme une fiche à part entière, avec ses outils, ses risques, ses contrôles, ses responsables et ses preuves, de sorte que la réponse à un auditeur soit un rapport, pas une reconstitution.