D'où viennent nos informations ?
De documents publics, et uniquement de ceux-là.
Notre point de départ est le catalogue MITRE ATLAS. MITRE est un organisme américain à but non lucratif, et ATLAS est la référence du domaine : il recense les techniques d'attaque contre les systèmes d'IA et les cas où elles ont été observées.
Pour savoir ce qui bloque encore, nous lisons ce que publient ceux qui testent ces systèmes : les instituts publics d'évaluation, comme l'AI Security Institute britannique, les laboratoires qui évaluent leurs propres modèles, les rapports d'incidents, et les fournisseurs qui décrivent leurs contrôles.
Comment les trions-nous ?
Nous cherchons des verrous. Un verrou, c'est une défense qui tient encore : ce qui manque pour qu'une attaque devienne possible.
La règle essentielle : le verrou doit être écrit noir sur blanc dans un document publié. Nous ne le devinons jamais. Quand personne n'a vérifié si une défense tient encore, nous l'écrivons tel quel : non testé. C'est une information en soi, et personne ne la publie.
Pour aller plus loin : les huit types de défenses
Capacité (le modèle ne sait pas encore faire), ressource (argent, calcul), identité (paiement, compte, pièce d'identité), accès (droits privilégiés), durée (tenir sans être détecté), savoir tacite (un savoir-faire absent des textes), contrôle installé (quelqu'un le maintient volontairement : limite de débit, filtre, bac à sable) et non testé.
Chaque verrou reçoit un seul type. Si deux types conviennent, il est classé non testé plutôt que tranché au jugé.
Que refusons-nous de publier ?
Pour des raisons évidentes, une entrée n'indique jamais comment contourner la défense.
Souvent, il suffit de reformuler. « La vérification d'identité des fournisseurs de calcul bloque l'ouverture autonome d'un compte » est un verrou. Nous ne nommons pas le fournisseur qui ne la pratique pas : ce serait un mode d'emploi d'attaque.
Quand la reformulation est impossible, l'entrée n'est ni publiée ni conservée. C'est arrivé deux fois sur les treize candidats examinés pour la liste du 26 septembre, avec des sources par ailleurs excellentes.
Que ne savons-nous pas ?
Trois choses, que nous écrivons plutôt que de les taire.
- Le catalogue enregistre ce qui a été documenté. Nous ne savons pas encore distinguer un domaine qui accélère d'un catalogue mieux tenu.
- Les tests publics se font sans défenseur. Les bancs d'essai des évaluateurs n'ont ni équipe de surveillance, ni détection. On ne sait donc pas ce que donnerait la même attaque contre un système bien défendu.
- Ce qui bloquait hier peut céder demain. Quatre limites des modèles publiées en mars étaient franchies en mai. Ce sont quatre observations, pas une loi générale, mais elles suffisent : notre liste dit l'état à une date, et chaque entrée porte la sienne.
Pourquoi la liste est datée
Nous voulions d'abord une liste qui reste valable dans le temps. C'est impossible, et nous l'avons mesuré.
Avec une règle écrite avant tout comptage, un seul scénario sur dix remplissait les conditions d'une liste durable. Avec une règle écrite, elle aussi, avant tout comptage, mais pour un état à une date, huit candidats sur treize les remplissent. Nous publions les deux résultats côte à côte, et les deux règles.
Comment nous vérifier ?
Tout ce que nous affirmons peut être refait par quelqu'un d'autre.
- Chaque verrou cite sa source.
- Chaque chiffre se recalcule d'une seule commande, à partir de sources publiques dont la version est figée.
- L'article est archivé avec un identifiant permanent (DOI), qui date ce que nous avons publié et empêche de le réécrire après coup.
Nous publions aussi nos échecs. Avant cette liste, nous avons tenté de construire un outil qui reconstitue automatiquement des scénarios d'attaque. Le test était fixé à l'avance, et l'outil ne l'a pas passé. Nous avons publié ce résultat négatif, avec de quoi le vérifier.