OWASP AISVS 1.0 : une checklist testable pour vérifier la sécurité des applications IA

De quoi s’agit-il ?

L’AI Security Verification Standard (AISVS) est un projet communautaire d’OWASP qui fait passer la sécurité de l’IA d’un ensemble de principes à une checklist réellement testable. OWASP a publié la première version stable, AISVS 1.0, le 24 juin 2026 (selon la page officielle du projet ; l’analyse de LRQA est datée du 29 juin 2026) ; elle est sous licence CC BY-SA 4.0 et a été fondée par Jim Manico, l’équipe actuelle comprenant notamment Otto Sulin, Rico Komenda, Russ Memisyazici et Raza Sharif. Le standard est explicitement modelé sur l’ancien OWASP Application Security Verification Standard (ASVS) : chaque entrée est rédigée pour être vérifiable, testable et implémentable, de sorte qu’un auditeur, un pentester ou un pipeline CI/CD puisse la valider ou non plutôt que d’en débattre. Point important, OWASP précise ce qu’AISVS n’est pas : ni un cadre de gouvernance, ni une méthodologie de gestion des risques, ni une liste d’outils recommandés. Il fournit la couche de contrôles techniques vers laquelle pointent des cadres comme le NIST AI RMF, l’ISO/IEC 42001, l’OWASP Top 10 pour les applications LLM et l’OWASP Top 10 pour les applications agentiques, sans que ceux-ci ne la spécifient eux-mêmes.

Comment ça fonctionne

AISVS 1.0 est organisé en 14 chapitres d’exigences couvrant l’ensemble du cycle de vie de l’IA : intégrité et traçabilité des données d’entraînement, validation des entrées, gestion du cycle de vie et du changement du modèle, sécurité de l’infrastructure et du déploiement, contrôle d’accès et identité, sécurité de la chaîne d’approvisionnement des modèles et des données, comportement et contrôle des sorties du modèle, sécurité de la mémoire/des embeddings/des bases vectorielles, orchestration autonome et action agentique, sécurité du Model Context Protocol (MCP), robustesse adverse, protection de la vie privée et des données personnelles, supervision et journalisation, et supervision humaine. Chaque exigence porte un niveau de vérification de 1 à 3 — le niveau 1 est une base que tout système devrait atteindre, le niveau 2 vise les systèmes en production et traitant des données personnelles, le niveau 3 concerne les environnements à forte assurance ; OWASP recommande que la plupart des systèmes en production visent au moins le niveau 2. Les exigences utilisent un identifiant stable au format C<chapitre>.<section>.<exigence>, préfixé par la version pour la citation — par exemple v1.0-C9.4.3, qui impose que les journaux d’audit soient inviolables via un stockage append-only/WORM, un chaînage cryptographique par hachage, ou une garantie d’intégrité équivalente vérifiable de manière indépendante. Le wiki de recherche qui alimente le standard couvre 191 exigences sur 60 pages, et le dossier gelé 1.0/en fait foi pour le texte publié.

Pourquoi c’est important

Pour quiconque met en production des fonctionnalités LLM, l’intérêt est que la sécurité de l’IA devient mesurable. Un conseil d’administration peut approuver des politiques IA et un comité des risques tenir un registre des modèles, mais rien de tout cela ne prouve que les contrôles fonctionnent ; AISVS donne aux équipes de sécurité une base reproductible à tester pour produire des preuves. Les deux chapitres les plus pertinents pour la menace actuelle sont ceux dédiés à l’agentique et à MCP. Le chapitre d’orchestration et d’action agentique (C9) couvre les budgets d’exécution, le contrôle des boucles, les disjoncteurs, l’approbation humaine pour les actions à fort impact, l’isolation des outils, l’identité de l’agent, l’autorisation à l’exécution et les mécanismes de kill-switch — précisément les contrôles qui réduisent l’écart entre la sortie d’un modèle et son impact opérationnel réel. Le chapitre MCP (C10) couvre les serveurs MCP en liste blanche, la validation des jetons d’accès par requête, la validation des claims OAuth 2.1, l’autorisation au niveau de l’outil, le transport sécurisé, la validation de schéma et le filtrage des réponses des outils MCP pour détecter l’injection indirecte avant qu’elles n’atteignent le contexte du modèle. Ce dernier point correspond directement aux classes d’injection indirecte et d’empoisonnement d’outils qui alimentent un flux continu de divulgations en 2026.

Défenses

AISVS est lui-même un instrument défensif ; la question pratique est donc celle de son adoption. Commencez par inventorier vos systèmes IA et attribuez à chacun un niveau cible selon le palier de risque : niveau 1 pour les outils internes ou à faible risque, niveau 2 par défaut pour les systèmes en production et exposés aux clients, niveau 3 lorsque l’exposition réglementaire ou la pression adverse justifie une assurance plus profonde. Traitez les exigences comme une bibliothèque de contrôles intégrée aux revues de conception, à la modélisation des menaces, à la revue de code et aux barrières CI/CD — pas comme une checklist d’audit annuelle. Priorisez les chapitres qui correspondent à votre architecture : les équipes exploitant des agents autonomes travailleront d’abord C9 et C10, les déploiements RAG le chapitre mémoire et bases vectorielles, et tout système traitant des données personnelles le chapitre vie privée. Référencez des identifiants d’exigences précis dans le périmètre des pentests et les questionnaires d’achat fournisseur, afin que les tiers soient tenus au même standard testable. Comme AISVS complète l’ISO/IEC 42001 et le NIST AI RMF plutôt que de les remplacer, faites remonter ses contrôles techniques vers le cadre de gouvernance sur lequel votre organisation reporte déjà, pour que les preuves pass/fail s’intègrent au reporting d’assurance existant.

Statut

Il s’agit de la sortie d’un standard défensif, pas d’une vulnérabilité. Les chiffres ci-dessous proviennent du dépôt officiel OWASP et de la page projet.

Élément	Détail
Projet	OWASP AI Security Verification Standard (AISVS), fondé par Jim Manico
Sortie	Version 1.0, 24 juin 2026 (selon la page projet OWASP ; analyse LRQA datée du 29 juin 2026) ; dossier 1.0/en gelé
Structure	14 chapitres d’exigences couvrant le cycle de vie de l’IA ; trois niveaux de vérification (1/2/3)
Périmètre agent/MCP	C9 orchestration et action agentique ; C10 sécurité du Model Context Protocol
Format d’exigence	C<chapitre>.<section>.<exigence>, cité v1.0-Cx.y.z ; wiki de recherche : 191 exigences sur 60 pages
Positionnement	Couche de contrôles techniques complétant NIST AI RMF, ISO/IEC 42001, OWASP Top 10 LLM et agentique ; pas un cadre de gouvernance
Licence	CC BY-SA 4.0