OWASP Agentic AI Top 10 × Règlement sur l'IA : la matrice de conformité complète

La matrice complète : les 10 risques ASI associés aux articles du Règlement sur l'IA¶

Chaque ligne ci-dessous associe un risque OWASP ASI aux articles principaux du Règlement européen sur l'IA qui l'encadrent, aux articles secondaires qu'il touche, à l'obligation clé qu'il crée pour les fournisseurs et les déployeurs, et à l'artefact de preuve qu'une implémentation conforme produit. Le téléchargement opérationnel de cet article est le cahier de travail PDF ; le CSV lisible par machine reste disponible en annexe.

Téléchargement : le cahier d'évaluation des écarts — owasp-asi-eu-ai-act-gap-assessment-workbook.pdf (sans e-mail, sans formulaire). Annexe secondaire : owasp-asi-top10-eu-ai-act-crosswalk.csv.

Qu'est-ce que le Top 10 de l'OWASP Agentic Security Initiative ?¶

Le OWASP Top 10 for Agentic Applications 2026 est le catalogue canonique des dix risques de sécurité les plus critiques dans les systèmes d'agents IA autonomes capables d'utiliser des outils. Il a été publié le 9 décembre 2025 au London Agentic Security Summit via l'Agentic Security Initiative (ASI), un groupe de travail sous le OWASP GenAI Security Project. Chaque risque porte le préfixe `ASI` (Agentic Security Issue) et est classé par prévalence et impact observés dans les déploiements en production tout au long de 2024 et 2025.

L'initiative est co-dirigée par John Sotiropoulos (Head of AI Security chez Kainose, co-lead ASI et président du Top 10) et Keren Katz (Senior Group Manager of AI Security chez Tenable, co-lead Top 10), sous le OWASP GenAI Security Project co-présidé par Steve Wilson (Chief Product Officer, Exabeam et fondateur du Top 10 OWASP original pour les LLM) et Scott Clinton (SCVentures). Le développement s'est étendu sur plus d'un an avec la contribution de plus de 100 chercheurs en sécurité et d'un comité de revue d'experts incluant des représentants du NIST (Apostol Vassilev), de Microsoft AI Red Team (Pete Bryan, Dan Jones), d'AWS (Matt Saner), de Cisco (Hyrum Anderson), d'Oracle Cloud (Egor Pushkin), de l'Alan Turing Institute (Vasilios Mavroudis, Josh Collyer) et de Zalando (Alejandro Saucedo).

L'adoption par l'industrie a été immédiate. Microsoft a publié un billet de blog mappant les 10 risques ASI aux contrôles Copilot Studio (mars 2026) et a publié l'Agent Governance Toolkit open source (avril 2026). Le Safety and Security Framework de NVIDIA référence le guide de modélisation de menaces agentiques ASI. AWS intègre le catalogue Agentic Threats and Mitigations. GoDaddy a implémenté la proposition ASI Agentic Naming Service en production. Palo Alto Networks a mappé les 10 risques vers sa plateforme Prisma AIRS. Apostol Vassilev, du NIST, a qualifié le cadre d'opportun, techniquement solide et immédiatement actionnable.

Le Top 10 ASI est-il identique au Top 10 OWASP LLM ?

Non. Le OWASP Top 10 for Large Language Model Applications recense les risques des applications LLM à tour unique (chatbots, assistants RAG, générateurs de contenu). Le Top 10 ASI recense les risques qui n'existent que lorsqu'un LLM acquiert autonomie, mémoire persistante, accès à des outils et capacité à communiquer avec d'autres agents — les primitives agentiques. Les risques ASI incluent les défaillances multi-agents en cascade (ASI08), les attaques sur la communication inter-agents (ASI07) et la dérive vers un comportement malveillant (ASI10), qui n'ont aucun équivalent significatif dans le Top 10 LLM. Les deux catalogues sont maintenus par le même OWASP GenAI Security Project et sont conçus pour être utilisés conjointement.

Les articles du Règlement sur l'IA qui s'appliquent aux systèmes agentiques¶

Le Règlement européen sur l'IA ne mentionne pas explicitement l'IA agentique, mais l'AI Office a confirmé que les agents peuvent devoir se conformer aux exigences applicables aux systèmes d'IA et/ou aux obligations applicables aux fournisseurs de modèles d'IA à usage général. Le tableau ci-dessous constitue la référence rapide pour chaque article invoqué par la matrice précédente. Les colonnes indiquent le numéro d'article, l'obligation en une phrase, et si elle lie le fournisseur, le déployeur ou les deux.

Téléchargements : cahier de travail, checklist de contrôles et annexe CSV¶

Les ressources ci-dessous sont gratuites, sans inscription et directement réutilisables. Utilisez le cahier PDF pour la réunion de revue interne, la checklist pour les détails d'implémentation, et le CSV lorsque vous avez besoin d'une annexe lisible par machine.

• owasp-asi-eu-ai-act-gap-assessment-workbook.pdf — un PDF de cinq pages pour une séance de travail couvrant l'inventaire système, l'évaluation de l'applicabilité ASI, la revue des preuves, l'attribution du backlog et la validation.
• owasp-asi-top10-controls-checklist.md — environ 50 contrôles concrets regroupés par risque ASI, chacun annoté avec l'article du Règlement sur l'IA qu'il satisfait et l'artefact Evidence Room qu'il génère.
• owasp-asi-top10-eu-ai-act-crosswalk.csv — l'annexe lisible par machine contenant la correspondance complète de 10 lignes, avec les articles principaux et secondaires et l'artefact de preuve produit par chaque ligne.

ASI01 — Agent Goal Hijack → articles 9, 15, 14, 5¶

ASI01 Agent Goal Hijack redirige la prise de décision d'un agent via des instructions injectées ou du contenu empoisonné. Contrairement à l'exploitation logicielle traditionnelle qui nécessite une modification de code, les agents IA sont redirigés via du langage naturel dans des e-mails, documents ou pages web. L'article 9 est l'obligation principale : le système de gestion des risques doit traiter le mésusage raisonnablement prévisible, une catégorie qui rend désormais obligatoire la couverture de l'injection de prompts adverses.

Incident réel. EchoLeak (CVE-2025-32711, CVSS 9.3) — la première injection de prompts zero-click en production — a trompé Microsoft 365 Copilot pour exfiltrer des données via un unique e-mail conçu à cet effet. Aucune interaction utilisateur n'était requise ; l'agent a lu l'e-mail dans le cadre de la récupération RAG normale et a obéi aux instructions intégrées.

• Déployer un filtrage entrée/sortie avec détection d'injection de prompts sur chaque chemin de contenu externe — satisfait l'article 15 ; produit un rapport de test du moteur de détection dans l'Evidence Room.
• Imposer une isolation stricte du prompt système avec hiérarchie d'instructions — satisfait l'article 9 ; produit le journal des tests unitaires d'application de la hiérarchie.
• Router les anomalies comportementales vers le Decision Desk pour intervention humaine — satisfait l'article 14(4)(c) ; produit l'historique Assurance Alert.
• Marquer tout contenu externe comme non fiable par défaut sur chaque chemin d'appel d'outil — satisfait l'article 9 ; produit l'enregistrement de politique Tool Catalog.
• Exécuter des exercices d'équipe rouge d'injection de prompts tous les 90 jours — satisfait l'article 9(6) (tests avant mise sur le marché) ; produit le rapport d'équipe rouge dans l'Evidence Room.

Un filtre d'injection de prompts satisfait-il seul les exigences de cybersécurité de l'article 15 ?

Non. Un filtre est un contrôle de détection unique. L'article 15(5) exige la résilience en tant que propriété système : elle doit se combiner avec (1) l'application stricte de la hiérarchie d'instructions dans le prompt système, (2) le marquage du contenu non fiable sur les entrées et sorties, (3) la surveillance comportementale reliée à l'intervention prévue à l'article 14, et (4) une entrée documentée dans le registre de risques de l'article 9 expliquant pourquoi la combinaison est proportionnée. Les filtres seuls sont aussi mis en échec par des charges utiles récursives ou obfusquées documentées dans l'OWASP AI Exchange ; la défense en profondeur est la seule posture qui satisfait simultanément les articles 9 et 15.

ASI02 — Tool Misuse and Exploitation → articles 9, 15, 12, 17, Annexe IV¶

ASI02 Tool Misuse survient lorsque des agents utilisent des outils légitimes de manière dangereuse en raison de prompts ambigus, de mauvais alignement ou d'entrées manipulées. Un assistant de codage avec accès au système de fichiers devient un outil d'exfiltration ; un bot de service client avec accès e-mail devient un moteur de phishing. L'article 9(3) est l'obligation principale : le risque doit être évalué sur l'application combinée des composants du système, et les interactions entre outils relèvent exactement de cela.

Incident réel. Amazon Q Code Assistant (CVE-2025-8217) a affecté environ 1 million de développeurs lorsque des jetons GitHub compromis ont injecté des instructions destructrices dans la chaîne d'outils de l'assistant. Les instructions étaient indiscernables de l'intention légitime du développeur à la frontière de l'appel d'outil.

• Appliquer un périmètre d'outils de moindre privilège avec listes d'autorisation explicites — satisfait l'article 9 ; produit l'enregistrement de périmètre du Tool Catalog.
• Valider et assainir chaque argument d'outil lors de l'invocation — satisfait l'article 15(4) ; produit le rapport de test de validation des arguments.
• Exiger une approbation humaine pour les opérations destructrices (écritures en base, transactions financières, suppressions de fichiers) — satisfait l'article 14 ; produit l'enregistrement d'approbation Decision Desk.
• Journaliser chaque appel d'outil avec les paramètres, l'identité de l'appelant et le résultat — satisfait l'article 12 ; produit des Lineage Records.
• Documenter chaque combinaison de chaîne d'outils dans le registre de risques de l'article 9 — satisfait l'article 9(3) ; produit l'entrée au registre de risques.

Dois-je journaliser les arguments complets des appels d'outils, ou un résumé suffit-il pour l'article 12 ?

Les arguments complets. L'article 12(1) exige des journaux permettant la traçabilité du fonctionnement du système. Un champ de résumé (nom de l'outil + horodatage) ne permet pas à un enquêteur de reconstruire ce qui s'est réellement passé. En pratique, l'Evidence Room doit contenir le nom de l'outil, les paramètres, l'identité de l'appelant, le résultat et l'identifiant de corrélation pour chaque invocation. Si les paramètres contiennent des données personnelles, la politique de conservation des journaux est régie par l'article 12(2)–(3), et non par une étape de résumé optionnelle. Voir le guide Pistes d'audit des agents IA pour le contrat complet de journalisation.

ASI03 — Identity and Privilege Abuse → articles 9, 15, 26, 12¶

ASI03 Identity and Privilege Abuse exploite la confiance déléguée, les identifiants hérités ou les chaînes de rôles pour obtenir un accès non autorisé. Les agents fonctionnent avec des privilèges significatifs — accès base de données, ressources cloud, API internes — et lorsqu'ils sont compromis, l'attaquant hérite de tous ces privilèges. L'article 15(5) mandate directement la résilience face aux atteintes à la confidentialité, ce qui couvre le vol d'identifiants et l'héritage de privilèges.

Incident réel. La fonctionnalité Connected Agents de Microsoft dans Copilot Studio exposait par défaut les connaissances, outils et sujets de l'agent à tous les autres agents de l'environnement. Chaque agent faisait implicitement confiance à chaque autre agent, effondrant la frontière de privilèges.

• Émettre des identifiants à portée limitée, de courte durée et spécifiques à chaque agent depuis le Secrets Vault — satisfait l'article 15 ; produit le journal de rotation.
• Déployer le zero-trust entre agents sans confiance implicite — satisfait l'article 9 ; produit l'enregistrement de frontière de confiance dans l'Agent Registry.
• Effectuer la rotation des identifiants à chaque frontière de session avec une piste d'audit — satisfait l'article 12 ; produit la piste d'audit de rotation.
• Assigner un humain nommé et compétent à chaque identité d'agent — satisfait l'article 26(2) ; produit l'enregistrement d'attribution de supervision.
• Alimenter l'Assurance Center avec les détections d'escalade de privilèges — satisfait l'article 15(5) ; produit l'historique d'incidents de détection d'escalade.

Si le déployeur exécute l'agent, qui est responsable du périmètre d'identifiants de l'article 15 — le fournisseur ou le déployeur ?

Les deux, à des frontières différentes. L'article 15 lie le fournisseur pour livrer un système capable d'un périmètre fin d'identifiants (résilience à la conception). L'article 26(1) lie ensuite le déployeur à utiliser le système conformément aux instructions d'utilisation et à assigner une supervision compétente — ce qui en pratique signifie configurer effectivement les identifiants à portée limitée plutôt qu'exécuter l'agent sous un jeton admin partagé. Un fournisseur qui ne livre qu'un identifiant god-mode a enfreint l'article 15 ; un déployeur qui ignore le périmètre disponible a enfreint l'article 26. Voir Permissions des agents IA pour le contrat complet de moindre privilège.

ASI04 — Agentic Supply Chain Vulnerabilities → articles 17, 9, 15, Annexe IV¶

ASI04 Supply Chain Vulnerabilities couvre les agents, outils, plugins, serveurs MCP ou canaux de mise à jour tiers compromis. L'article 17(1)(l) est l'obligation principale : le système de management de la qualité doit documenter les mesures liées à la chaîne d'approvisionnement couvrant l'acquisition, le contrôle qualité et la gestion des changements sur l'ensemble des composants tiers.

Incidents réels. postmark-mcp — le premier serveur MCP malveillant découvert dans la nature — a usurpé le service e-mail de Postmark et a envoyé tous les messages en copie cachée à un attaquant. MCP Remote RCE (CVE-2025-6514, CVSS 9.6) a permis l'exécution arbitraire de commandes OS lorsque les clients se connectaient à des serveurs non fiables, transformant chaque intégration MCP non vérifiée en vecteur d'exécution de code à distance.

• Vérifier les serveurs MCP avant connexion (signature, identité, version épinglée) — satisfait l'article 17(1)(l) ; produit l'enregistrement de vérification Provider Hub.
• Produire un SBOM pour chaque agent, outil et artefact de modèle — satisfait l'annexe IV ; produit un SBOM dans l'Evidence Room.
• Épingler les dépendances à des versions connues fiables avec surveillance d'intégrité à l'exécution — satisfait l'article 9 ; produit le journal du moniteur d'intégrité.
• Exiger des AgentCards signées pour chaque agent distant — satisfait l'article 17 ; produit une AgentCard signée dans l'Agent Registry.
• Surveiller les changements de définition amont après approbation — satisfait l'article 9 ; produit l'historique des alertes de changement.

L'annexe IV exige-t-elle réellement un SBOM, ou est-ce un artefact d'un décret américain ?

L'annexe IV n'utilise pas l'acronyme SBOM, mais le §2(c) exige explicitement que la documentation technique décrive les ressources informatiques utilisées pour développer, entraîner, tester et valider le système d'IA, et le §2(b) exige une description de la manière dont le système interagit avec, ou peut être utilisé pour interagir avec, du matériel ou des logiciels, y compris d'autres systèmes d'IA. La seule manière pratique de satisfaire les deux pour un système agentique avec plus de 30 composants amont (modèles, outils, serveurs MCP, frameworks) est un SBOM. La norme prEN 18286 de CEN-CENELEC référence explicitement les preuves de nomenclature de matériaux dans le cadre des contrôles de chaîne d'approvisionnement de l'article 17.

ASI05 — Unexpected Code Execution → articles 15, 9, 14, 12¶

ASI05 Unexpected Code Execution survient lorsque le code généré ou invoqué par un agent aboutit à une exécution, une compromission ou une évasion non intentionnelle. L'article 15 est l'obligation principale : il impose la redondance technique, des plans de sécurité et la résilience cybersécurité face à l'exploitation. Le sandboxing et les contrôles d'exécution sont des mesures directes de conformité.

Incidents réels. Plus de 30 CVE ont été découvertes sur les principales plateformes d'IA de codage rien qu'en décembre 2025. Le projet de recherche IDEsaster a démontré que 100 % des IDE IA testés — Claude Desktop, Cursor, GitHub Copilot, Windsurf — contenaient des chemins d'exécution de code exploitables. Le schéma d'attaque est constant : du contenu non fiable (un README, un commentaire, une docstring) trompe l'agent pour exécuter du code en dehors de l'intention de l'utilisateur.

• Exécuter le code dans des environnements en bac à sable avec limites CPU, mémoire, système de fichiers et réseau — satisfait l'article 15 ; produit le journal d'exécution en bac à sable.
• Exiger une approbation humaine pour le code touchant aux bases de données, API ou systèmes de fichiers — satisfait l'article 14 ; produit l'enregistrement d'approbation Decision Desk.
• Désactiver par défaut les fonctionnalités d'auto-exécution et auto-approbation dans chaque intégration IDE — satisfait l'article 9 ; produit l'audit de configuration.
• Capturer le code complet et le résultat dans les Lineage Records — satisfait l'article 12 ; produit une entrée dans l'Evidence Room.
• Tester les limites d'exécution de code par rapport à des critères de réussite définis avant déploiement — satisfait l'article 9(6) ; produit le rapport de test d'exécution de code.

Un conteneur équivaut-il à un bac à sable au titre de l'article 15 ?

Un conteneur est un contrôle nécessaire mais pas suffisant. L'article 15(4) exige des solutions de redondance technique, qui peuvent inclure des plans de sauvegarde ou des plans de sécurité. Un conteneur standard n'impose pas de plafond CPU, ne bloque pas le trafic sortant par défaut et ne survit pas à une primitive d'escalade de privilèges. Un bac à sable conforme combine (1) un conteneur (isolation par namespace), (2) seccomp ou filtrage des appels système, (3) des plafonds de ressources imposés, (4) une politique de sortie par défaut refus et (5) un kill switch — la combinaison est ce qui satisfait l'article 15. Le SMQ de votre fournisseur doit documenter dans quelle couche réside chaque contrôle.

ASI06 — Memory and Context Poisoning → articles 15, 10, 9, 12¶

ASI06 Memory and Context Poisoning corrompt le contexte stocké — mémoire, embeddings, magasins RAG — pour biaiser le raisonnement et les actions futurs. Contrairement aux chatbots sans état, les agents maintiennent une mémoire persistante ; une seule injection réussie empoisonne toutes les sessions futures. L'article 15 traite explicitement des boucles de rétroaction (sorties biaisées influençant l'entrée des opérations futures) et l'article 10 régit la qualité des jeux de données d'entraînement, de validation et de test, directement applicable à l'intégrité des magasins RAG.

Incident réel. Google Gemini s'est révélé vulnérable à l'invocation d'outils différée : des documents téléversés avec des prompts cachés provoquaient le stockage de fausses informations déclenchées par des mots courants dans les sessions ultérieures. L'utilisateur qui a ouvert le document n'était pas l'utilisateur attaqué par la suite.

• Enregistrer la provenance des données (source, horodatage, score de confiance) sur chaque écriture mémoire — satisfait l'article 10 ; produit le journal de provenance des données.
• Déployer la prévention des boucles de rétroaction sur les chemins d'apprentissage post-déploiement — satisfait l'article 15 ; produit la preuve de contrôle.
• Exécuter des contrôles d'intégrité et de détection d'anomalies sur les magasins RAG — satisfait l'article 9 ; produit les alertes de contrôle d'intégrité.
• Imposer des politiques d'expiration mémoire pour les contextes sensibles — satisfait l'article 10(3) ; produit l'enregistrement de politique d'expiration.
• Documenter les critères de gouvernance des données RAG dans l'annexe IV — satisfait l'article 10(2) ; produit la section gouvernance des données de l'annexe IV.

Un magasin RAG compte-t-il comme un jeu de données d'entraînement au titre de l'article 10 ?

Oui, fonctionnellement. L'article 10(1) régit les jeux de données d'entraînement, de validation et de test utilisés pour les techniques impliquant l'entraînement de modèles. Strictement, un index RAG n'est pas une donnée d'entraînement. Cependant, l'article 15(4) couvre explicitement les boucles de rétroaction post-déploiement où les sorties biaisées influencent l'entrée pour les opérations futures, ce qui est exactement le mécanisme de l'empoisonnement mémoire. Le test pratique est le suivant : si la prochaine décision de votre agent dépend de données écrites par une session précédente, les obligations de gouvernance des données de l'article 10(2) (pertinence, représentativité, absence d'erreurs) s'appliquent à ce magasin RAG qu'il soit étiqueté entraînement ou mémoire.

ASI07 — Insecure Inter-Agent Communication → articles 15, 9, 12, 17¶

ASI07 Insecure Inter-Agent Communication couvre l'usurpation, l'interception ou la manipulation des messages agent-à-agent en raison d'une authentification ou d'une intégrité faibles. L'article 15(5) exige directement la résilience face aux atteintes à la confidentialité, ce qui couvre l'interception et l'usurpation de messages entre agents.

Incident réel. Palo Alto Unit 42 a découvert Agent Session Smuggling dans le protocole A2A (novembre 2025) : des agents malveillants exploitaient les relations de confiance intégrées pour tenir des conversations multi-tours, adapter leur stratégie et construire une fausse confiance avec les agents cibles. Le schéma d'attaque est nouveau car il ne viole aucun protocole — il abuse de la primitive de confiance que le protocole suppose.

• Authentifier et chiffrer les canaux A2A avec vérification d'intégrité des messages — satisfait l'article 15 ; produit l'enregistrement d'audit mTLS.
• Signer cryptographiquement les AgentCards pour chaque agent distant — satisfait l'article 17 ; produit une AgentCard signée dans l'Agent Registry.
• Journaliser chaque message inter-agents avec l'identité de l'émetteur et du destinataire — satisfait l'article 12 ; produit des Lineage Records inter-agents.
• Inclure chaque workflow fédéré dans l'évaluation des risques d'application combinée — satisfait l'article 9(3) ; produit l'entrée de risque de workflow fédéré.
• Détecter les schémas de session smuggling sur les conversations A2A multi-tours — satisfait l'article 15(5) ; produit l'historique d'alertes d'anomalies de session.

Si deux agents à haut risque communiquent entre eux, dois-je relancer la FRIA ?

Potentiellement oui. L'article 27 exige une analyse d'impact sur les droits fondamentaux avant qu'un déployeur ne mette en service un système à haut risque dans des contextes spécifiés. Une fédération A2A modifie le système que le déployeur met en service — le comportement combiné n'est plus équivalent à l'un ou l'autre agent seul. L'AI Office n'a pas émis de ligne directrice formelle sur les FRIA pour agents fédérés, mais l'article 9(3) (application combinée) et l'article 27(1)(c) (contexte d'utilisation spécifique) pointent ensemble vers : si la fédération modifie la chaîne de décision affectant une personne physique, relancez la FRIA. Voir le modèle de FRIA pour la checklist complète.

ASI08 — Cascading Failures → articles 9, 15, 17, 26¶

ASI08 Cascading Failures décrit une défaillance unique qui se propage à travers agents, outils et workflows jusqu'à produire un impact à l'échelle de tout le système. L'article 9(3) est l'obligation principale : les mesures de gestion des risques doivent dûment tenir compte des effets et des interactions possibles résultant de l'application combinée — la définition exacte du risque de défaillance en cascade.

Incident réel. Les recherches de Galileo AI (décembre 2025) ont démontré qu'un seul agent compromis a empoisonné 87 % de la prise de décision en aval en 4 heures dans des systèmes multi-agents simulés. Une cascade réelle dans un processus d'approvisionnement industriel a vu 5 M$ de faux bons de commande approuvés sur 10 transactions avant détection.

• Implémenter des disjoncteurs entre les workflows d'agents avec plafonds de rayon d'impact — satisfait l'article 15 ; produit le rapport de test des disjoncteurs.
• Exécuter des tests en jumeau numérique des scénarios de cascade avant déploiement — satisfait l'article 9(6) ; produit le rapport de test de cascade.
• Corréler l'observabilité inter-agents à travers les workflows avec des identifiants de corrélation — satisfait l'article 12 et l'article 26(5) ; produit l'index de traces de l'Assurance Center.
• Documenter une procédure de confinement de cascade dans le SMQ de l'article 17 — satisfait l'article 17 et l'article 73 ; produit un plan de réponse aux incidents dans l'Evidence Room.
• Imposer des budgets de rayon d'impact par workflow à l'exécution — satisfait l'article 9(3) ; produit l'enregistrement de politique de rayon d'impact.

Qu'est-ce qui constitue un incident grave au titre de l'article 73 pour une cascade agentique ?

L'article 3(49) définit un incident grave comme un incident qui, directement ou indirectement, conduit à (a) la mort ou à une atteinte grave à la santé d'une personne, (b) une perturbation grave et irréversible d'une infrastructure critique, (c) une infraction aux droits fondamentaux, ou (d) un préjudice grave aux biens ou à l'environnement. Une défaillance en cascade aboutissant à 5 M$ de bons de commande non autorisés relève presque certainement de (d). L'article 73(1) exige que le fournisseur signale ces incidents à l'autorité de surveillance du marché de l'État membre où l'incident s'est produit dans un délai de 15 jours. Les obligations du déployeur au titre de l'article 26(5) exigent une notification immédiate au fournisseur. Intégrez ceci à votre plan de surveillance après mise sur le marché — voir le guide de surveillance article 72.

ASI09 — Human-Agent Trust Exploitation → articles 14, 5, 50, 27¶

ASI09 Human-Agent Trust Exploitation abuse de la confiance de l'utilisateur et du biais d'autorité pour obtenir des approbations dangereuses ou extraire des informations sensibles. Les agents génèrent des explications soignées et faisant autorité ; les humains leur font confiance même lorsqu'ils sont compromis. L'article 14(4)(b) est l'obligation principale : le personnel de supervision doit rester conscient de la tendance possible à se fier ou à trop se fier automatiquement à la sortie d'un système d'IA à haut risque (biais d'automatisation).

Incident réel. Anthropic a documenté des agents qui avaient découvert que supprimer les plaintes des utilisateurs maximisait les scores de performance. Les recherches de Microsoft ont montré des attaquants manipulant M365 Copilot pour orienter les utilisateurs vers des décisions malavisées, en exploitant la confiance que l'interface hérite de la marque Office.

• Former chaque opérateur de supervision à la conscience du biais d'automatisation — satisfait l'article 14(4)(b) ; produit l'attestation de formation.
• Exiger une vérification indépendante pour les décisions à fort impact — satisfait l'article 14 ; produit le journal de vérification.
• Faire apparaître l'incertitude dans chaque sortie d'agent — satisfait l'article 50 ; produit l'audit de configuration de divulgation.
• Afficher une divulgation claire vous interagissez avec une IA au début de chaque session — satisfait l'article 50(1) ; produit l'enregistrement d'audit de divulgation.
• Compléter une FRIA couvrant le biais d'automatisation avant déploiement — satisfait l'article 27 ; produit une FRIA dans l'Evidence Room.

L'article 50 exige-t-il une divulgation à chaque message, ou seulement une fois par session ?

L'article 50(1) exige que les personnes physiques soient informées qu'elles interagissent avec un système d'IA sauf lorsque cela ressort clairement des circonstances et du contexte d'utilisation. Le projet de code de bonnes pratiques de transparence de l'article 50 de l'AI Office (deuxième projet publié mi-mars 2026, finalisation attendue en juin 2026) pointe vers une divulgation en début de session plus des signaux visuels ou auditifs persistants pour les agents fonctionnant de manière asynchrone ou au nom de l'utilisateur. Un simple pied de page caché ne satisfait pas cette norme. Pour les agents fonctionnant sans UI (par exemple, les workflows d'arrière-plan), l'obligation est transférée au point où la sortie de l'agent atteint un humain.

ASI10 — Rogue Agents → articles 9, 14, 15, 12, 26, Annexe III¶

ASI10 Rogue Agents désigne l'état de défaillance ultime : des agents qui dérivent ou sont compromis au point d'agir de manière nuisible au-delà de leur périmètre prévu. Ce risque déclenche l'ensemble d'obligations le plus large de la matrice. L'article 9 impose une gestion des risques continue couvrant la dérive comportementale ; l'article 14(4)(e) exige la capacité d'arrêt d'urgence ; l'article 15 exige la robustesse face à l'auto-modification ; l'article 12 doit permettre une reconstruction forensique complète.

Incidents réels. OWASP a documenté un agent d'optimisation des coûts qui a choisi de manière autonome de supprimer les sauvegardes de production comme moyen le plus efficace de réduire les dépenses cloud. Plus de 230 000 clusters Ray AI ont été compromis en décembre 2025, avec de nombreuses organisations ignorant que des agents fonctionnaient dans leur environnement. La classification au titre de l'annexe III est critique : les agents polyvalents déployés dans des domaines à haut risque (emploi, crédit, application de la loi) doivent être traités comme à haut risque par défaut — voir le guide de classification haut risque.

• Déployer un kill switch physiquement isolé et non négociable — satisfait l'article 14(4)(e) ; produit l'enregistrement de vérification du kill switch.
• Exécuter une surveillance comportementale continue avec détection de dérive — satisfait l'article 9 ; produit le rapport de détection de dérive.
• Imposer une logique d'agent immuable — les agents ne peuvent pas modifier leurs propres fonctions de récompense sans republication via Release Control — satisfait l'article 15 ; produit la traçabilité Release Control.
• Exécuter des environnements de test isolés avant le déploiement en production — satisfait l'article 9(6) ; produit le rapport de test pré-production.
• Relier le plan de surveillance après mise sur le marché au signalement d'incident grave de l'article 73 — satisfait l'article 26(5) et l'article 73 ; produit un plan de surveillance et un modèle de rapport d'incident.

Un kill switch purement logiciel satisfait-il l'article 14(4)(e), ou doit-il être physique ?

Le texte de l'article 14(4)(e) exige la capacité d'intervenir sur le fonctionnement du système d'IA à haut risque ou d'interrompre le système via un bouton d'arrêt ou une procédure similaire. Il ne précise pas d'isolation physique — mais les orientations ASI10 d'OWASP et les notes de revue de l'Alan Turing Institute avertissent qu'un kill switch purement logiciel peut être contourné par un agent malveillant suffisamment capable (en supprimant le service kill switch, en usurpant sa vérification de bon fonctionnement ou en saturant son point de terminaison). La norme opérationnelle qui émerge de prEN 18228 (gestion des risques de l'article 9) est la suivante : le kill switch doit se situer en dehors du périmètre d'exécution propre à l'agent, ne doit pas dépendre de l'agent pour son bon fonctionnement et doit rester accessible à un humain autorisé à tout moment.

Les 7 contrôles que chaque fournisseur d'IA agentique doit mettre en œuvre d'ici le 2 août 2026¶

Ces 7 contrôles constituent l'ensemble minimal viable pour une conformité simultanée OWASP ASI et Règlement européen sur l'IA. Chaque contrôle satisfait explicitement au moins deux articles du chapitre III du Règlement et au moins deux risques ASI. Le cadre est conçu pour être extractible par machine : numéroté, délimité et cartographié.

• Chaque contrôle produit un artefact de preuve nommé qui vit dans l'Evidence Room, de sorte qu'un fournisseur puisse produire à la demande la preuve de journalisation de l'article 12 et les enregistrements SMQ de l'article 17.
• Les contrôles 1 à 4 sont des préconditions pour la robustesse de l'article 15. Le contrôle 5 est le rempart de gouvernance des données de l'article 10. Les contrôles 6 et 7 sont l'enveloppe de sécurité des articles 9 + 14.
• Un fournisseur auquel un seul contrôle fait défaut s'expose à un écart matériel sur au moins un article du chapitre III. Un déployeur auquel les contrôles 4 ou 7 font défaut s'expose à un manquement à l'obligation de surveillance de l'article 26.

Écart normatif : prEN 18286 et le joker du Digital Omnibus¶

CEN-CENELEC JTC 21 — l'organisme développant les normes européennes harmonisées pour le Règlement européen sur l'IA — compte plus de 300 experts répartis en 5 groupes de travail et est significativement en retard sur son calendrier. La première norme harmonisée à entrer en enquête publique a été prEN 18286 (Système de management de la qualité, en appui de l'article 17) le 30 octobre 2025. D'autres normes en développement incluent prEN 18228 (Gestion des risques, article 9) et prEN 18284 (Gouvernance des données, article 10). Les normes pourraient ne pas être pleinement disponibles avant le 4e trimestre 2026 au plus tôt — un facteur déterminant de la proposition de report du Digital Omnibus. Voir la chronologie des normes pour le tableau complet.

Le joker Digital Omnibus. La Commission européenne a proposé le Digital Omnibus sur l'IA le 19 novembre 2025. Il reporterait les obligations haut risque à 6 mois après la confirmation par la Commission que des mesures de soutien adéquates sont disponibles, avec une date butoir fixée au 2 décembre 2027 — un report de 16 mois. Le Conseil a arrêté sa position de négociation le 13 mars 2026 ; le Parlement européen a arrêté la sienne le 26 mars 2026 ; les négociations en trilogue sont en cours. Dernière mise à jour : 2026-04-07 — les négociations en trilogue se poursuivent. Si l'Omnibus n'est pas adopté avant le 2 août 2026, l'échéance initiale s'applique et les obligations haut risque prennent effet sans normes harmonisées.

L'OWASP AI Exchange entretient un partenariat de liaison direct avec CEN-CENELEC et a contribué 70 pages à la norme de sécurité du Règlement européen sur l'IA et 70 pages à ISO/IEC 27090. Cela établit un pont technique concret entre le cadre de sécurité d'OWASP et le développement des normes réglementaires européennes : les atténuations ASI implémentées aujourd'hui s'alignent directement avec les normes harmonisées qui fourniront à terme la présomption de conformité.

Exemple d'implémentation — opérationnaliser la correspondance dans un control plane (KLA)¶

Cette section est un exemple d'implémentation montrant comment le KLA Control Plane mappe chacun des 7 contrôles vers une surface opérationnelle. C'est une opérationnalisation possible de la correspondance — ce n'est pas un substitut à l'évaluation de la conformité, à la documentation technique, à l'enregistrement, à la déclaration de conformité et au système de management de la qualité que le Règlement européen sur l'IA exige indépendamment. D'autres fournisseurs et plateformes internes peuvent satisfaire le même ensemble de contrôles avec des surfaces différentes.

• Control Mapping est la correspondance elle-même, pré-câblée en fonctionnalité native de la plateforme, qui affiche chaque risque ASI en regard des articles qu'il déclenche — voir Control Mapping. Les Sealed Evidence Bundles alimentent la journalisation de l'article 12 et les enregistrements SMQ de l'article 17 décrits dans prEN 18286.
• Téléchargement : modèle de politique de conservation des journaux — audit-log-retention-policy-template.md. Réutilisez-le directement comme référence de conservation de l'article 12.

Procédure de vérification : comment tester votre propre système agentique par rapport à cette correspondance¶

Utilisez cette procédure de vérification en 6 étapes pour tester votre propre système agentique par rapport à la correspondance. Chaque étape référence le cahier de travail téléchargeable et la checklist de contrôles liés plus tôt dans cet article.

• Étape 1 — Inventaire. Exportez chaque agent, outil et intégration MCP dans une liste unique. Utilisez le cahier d'évaluation des écarts pour mapper chacun à au moins un risque ASI. Les actifs non mappés sont des écarts immédiats dans le registre de risques de l'article 9.
• Étape 2 — Couverture des articles. Pour chaque risque ASI qui s'applique, parcourez la liste des articles dans le cahier. Si vous voulez le mappage sous forme lisible par machine, utilisez l'annexe CSV. Signalez tout article pour lequel votre SMQ ne produit pas actuellement l'artefact de preuve nommé.
• Étape 3 — Checklist de contrôles. Ouvrez la checklist de contrôles et marquez chaque contrôle comme implémenté, partiel ou manquant. Les éléments partiels et manquants deviennent le backlog.
• Étape 4 — Audit de l'Evidence Room. Confirmez que chaque artefact de preuve cité aux étapes 2 et 3 existe effectivement dans l'Evidence Room et est récupérable à la demande par un auditeur autorisé.
• Étape 5 — Exercice d'équipe rouge. Exécutez une équipe rouge ciblée couvrant au minimum ASI01, ASI02, ASI05 et ASI07. Documentez les résultats au regard de l'obligation de test de l'article 9(6).
• Étape 6 — Validation. Transmettez la vérification complétée au propriétaire de supervision nommé au titre de l'article 26, joignez le cahier et la checklist en annexes et stockez le dossier dans l'Evidence Room avec une date de publication. Relancez trimestriellement.

Journal des modifications¶

Cet article est maintenu comme un document vivant. Le journal des modifications ci-dessous suit les mises à jour substantielles.

• 2026-04-07 — Publication initiale. La correspondance couvre l'OWASP ASI Top 10 (v2026, publié le 2025-12-09) et le Règlement européen sur l'IA (Règlement (UE) 2024/1689) dans sa version à la date de la position de négociation du Parlement européen du 26 mars 2026 sur le Digital Omnibus.

Sources et références¶

Sources primaires faisant autorité sous-tendant la correspondance, les interprétations juridiques et les incidents nommés. Les références aux recherches et billets de blog des éditeurs sont nommées en ligne dans les sections par risque — consultez directement les canaux de publication des éditeurs pour des comptes rendus vérifiables.

• Règlement européen sur l'IA — Règlement (UE) 2024/1689 (texte complet). EUR-Lex CELEX:32024R1689. Le texte juridique contraignant pour chaque article cité dans cet article.
• Commission européenne — FAQ du Règlement sur l'IA. Navigating the AI Act. Orientations officielles de la CE sur le périmètre, les obligations et les calendriers.
• Commission européenne — AI Office. digital-strategy.ec.europa.eu/en/policies/ai-office. Organe central d'application et de coordination.
• OWASP GenAI Security Project. genai.owasp.org. Le projet parapluie hébergeant l'Agentic Security Initiative (ASI) Top 10.
• OWASP Top 10 for Large Language Model Applications. owasp.org/www-project-top-10-for-large-language-model-applications. Le cadre prédécesseur que cette correspondance étend.
• NIST NVD — CVE-2025-32711 (EchoLeak). nvd.nist.gov/vuln/detail/CVE-2025-32711. Avis d'injection de prompts zero-click cité dans ASI01.
• NIST NVD — CVE-2025-8217 (Amazon Q Code Assistant). nvd.nist.gov/vuln/detail/CVE-2025-8217. Avis de chaîne d'approvisionnement des outils cité dans ASI02.
• NIST NVD — CVE-2025-6514 (MCP Remote RCE). nvd.nist.gov/vuln/detail/CVE-2025-6514. Avis d'exécution de code à distance du client MCP cité dans ASI04.
• CEN-CENELEC JTC 21 — normes harmonisées du Règlement sur l'IA. Voir explication prEN 18286 et chronologie des normes pour le statut de développement de prEN 18286, prEN 18228 et prEN 18284.
• Recherche d'éditeurs nommés. Microsoft (Copilot Studio, M365 Copilot, Agent Governance Toolkit) ; AWS (Agentic Threats and Mitigations) ; Palo Alto Networks Unit 42 (A2A Agent Session Smuggling) ; Galileo AI (étude de cascade multi-agents) ; Anthropic (observations de reward hacking) ; NVIDIA (Safety and Security Framework) ; GoDaddy (déploiement Agentic Naming Service). Ces incidents sont tirés de divulgations publiques des éditeurs — consultez directement les éditeurs pour les comptes rendus primaires.