L'Archive des incidents d'Orca AI : 354 incidents réels d'agents IA, chacun avec un reçu

Une équipe de sécurité peut vous dire précisément dans quelle mesure un modèle résiste à l'injection de prompt dans un harnais de test. Ce que presque personne ne peut vous dire, c'est combien d'organisations ont réellement été compromises par un agent le mois dernier, lesquelles de ces intrusions avaient une victime confirmée, et lesquels des chiffres cités dans le rapport provenaient du fournisseur plutôt que d'un régulateur. Cet écart — entre ce qu'un modèle pourrait faire et ce qui s'est déjà produit — est l'écart que a href="https://www.orcarouter.ai/incident-archive">Orca AI Incident Archive/a> a été conçue pour combler. Il a été mis en ligne le 23 septembre 2026 et, à la date d'arrêté des données du 22 septembre, contient 354 enregistrements issus de 593 sources uniques.

Remarque sur l'exactitude : chaque chiffre ci-dessous est lu à partir du fichier publié par l'archive elle-même code>dist/stats.json/code> à la version 2026-09-22, ainsi que de la page en ligne. L'annonce de lancement du 23 septembre mentionnait 340 enregistrements, 548 sources et 126 cas de préjudice confirmé ; il s'agissait des chiffres au moment de la publication, et comme l'archive est mise à jour en continu, les deux ensembles diffèrent d'environ une journée de collecte. En cas de divergence entre le README de l'archive et sa page en ligne sur un numéro de badge pendant le développement, ce sont la page en ligne et l'export JSON qui font foi.

Ce que contient réellement l'archive

Ce n'est pas un fil d'actualité et ce n'est pas une liste de CVE. Chaque entrée est un seul fichier Markdown avec un frontmatter structuré, classé sous le mois où l'événement s'est produit, et chaque entrée comporte au moins une source. Le jeu de données est publié sous CC BY 4.0 et mis en miroir dans un dépôt public, de sorte que l'ensemble peut être cloné, comparé et cité plutôt que capturé en capture d'écran.

La fenêtre de couverture s’étend sur 22 mois, d’un précurseur de décembre 2024 jusqu’au 22 septembre 2026, et la répartition est la partie intéressante. La gravité se répartit en 45 critiques, 139 élevées, 77 moyennes, 8 faibles et 85 informatives. La confiance des sources se répartit en 302 de grade A, 47 de grade B, 2 de grade C et 3 de grade D. Un préjudice réel confirmé est enregistré pour 127 enregistrements, explicitement exclu pour 142, et laissé à null pour 85.

Ces trois derniers chiffres sont la raison pour laquelle l’archive mérite d’être lue attentivement plutôt que parcourue en diagonale. Un total de 354 entrées n’est pas un total de 354 incidents. Seules 138 d’entre elles sont même classées comme des incidents ; les autres sont des divulgations de vulnérabilités, des démonstrations de recherche, des rapports sur les menaces et des mesures politiques. C’est précisément en les comptant tous les cinq ensemble que l’on obtient un chiffre de gros titre erroné, et c’est pourquoi l’archive les distingue et vous permet de filtrer.

Pourquoi « un jailbreak n'est pas un incident » est tout l'enjeu

La plupart des collections d’événements de sécurité liés à l’IA escamotent une distinction : un agent qui a réellement causé des dommages n’est pas la même chose qu’un chercheur démontrant qu’il pourrait le faire. C’est cet amalgame qui transforme une démonstration de conférence en gros titre sur une violation, et c’est ce que l’archive est conçue pour refuser.

Trois champs supportent ce poids. code>real_harm/code> consigne si une victime a été confirmée. code>ai_involvement/code> consigne si une source primaire — le fournisseur, la victime, les forces de l'ordre ou un rapport officiel — a confirmé le rôle de l'IA, les attributions contestées étant conservées dans le jeu de données mais étiquetées. code>kind/code> consigne le type de document que constitue l'entrée. Un enregistrement sans source n'est pas intégré. Un enregistrement comportant des preuves contradictoires est marqué comme contesté plutôt que tranché dans le sens qui se lit le mieux. Lorsque de nouvelles preuves arrivent, l'enregistrement est mis à jour et la modification est inscrite dans son historique de révision plutôt que d'être écrasée en silence.

L'archive a appliqué cette règle à elle-même. Au cours de ses propres cycles de vérification, elle a supprimé deux entrées qui ne pouvaient pas être étayées, corrigé une affirmation largement reprise sur la vitesse de progression d'une intrusion, et revu à la baisse le niveau de confiance d'une troisième entrée lorsque les éléments de preuve sous-jacents se sont révélés être de seconde main. Une base de données d'incidents qui n'a jamais rien supprimé est une base de données qui n'a pas été vérifiée.

Les douze surfaces d'attaque selon lesquelles il trie

Chaque enregistrement est étiqueté avec un ou plusieurs de douze types, et chaque type porte son propre décompte mois par mois. Gouvernance et politiques est la plus grande catégorie avec 65 enregistrements, mais un seul de ceux-ci a un préjudice confirmé — ce qui est la forme correcte pour l’activité réglementaire et une donnée trompeuse à citer comme nombre d’incidents. L’abus d’identifiants suit avec 55, avec 40 victimes confirmées, la plus forte densité de préjudice de l’ensemble. Agent utilisé comme arme se situe à 51 avec 28 confirmés. L’injection indirecte de prompt compte 45 enregistrements mais seulement 5 avec préjudice confirmé, ce qui est l’illustration la plus claire de la fracture entre capacité et conséquence dans tout le jeu de données : c’est la classe d’attaque la plus étudiée et l’une des moins productives sur le terrain. L’empoisonnement de la chaîne d’approvisionnement, avec 36 enregistrements, compte 27 victimes confirmées — le pire ratio du tableau.

Septembre 2026 est le mois qui fait la démonstration.

Cinquante et un enregistrements ont été recensés rien qu'en septembre 2026, soit plus du double de n'importe quel mois précédent de la période. Il ne s'agit pas d'un effondrement soudain de la sécurité. C'est un mois où la tenue des registres a enfin rattrapé une année d'événements accumulés, et c'est la composition qui compte : des entrées critiques pour un code>.git/config/code> malveillant qui exécute du code d'attaquant dans sept agents de codage avant même que le modèle ne soit contacté, pour une faille Langflow exploitée dans la nature, pour une campagne d'essaim d'agents d'IA chez un fournisseur de gestion d'impression, et pour un ver npm qui s'introduit dans la chaîne en amont. À côté d'elles figurent des entrées informatives sur le standard de contrôle des agents de l'OWASP, un discours sur l'état de l'Union de l'UE qui a cité des évasions d'agents, et une note d'un panel des Nations unies qui a considéré un incident comme un avertissement de perte de contrôle.

Les entrées coréennes, et ce qu'un champ de région ne signifie pas

Le champ de l'archive code>region/code> indique où un événement s'est réellement produit, et non où le fournisseur a son siège social — les divulgations de fournisseurs transfrontaliers sont toujours déposées comme mondiales, c'est pourquoi 291 des 354 enregistrements ne portent aucune balise de pays unique. Deux enregistrements portent la balise KR, tous deux étant des entrées de politique avec un sourçage de grade A et aucun préjudice confirmé : le retrait de DeepSeek des magasins d'applications nationaux par la Corée du Sud en avril 2025, et l'interdiction à l'échelle de l'entreprise d'OpenClaw adoptée par Naver, Kakao et Karrot en février 2026.

Cette retenue est délibérée. Un décompte régional de deux n’est pas une affirmation selon laquelle la Corée a connu deux événements de sécurité liés à l’IA. C’est l’affirmation que deux événements survenus dans la fenêtre temporelle ont eu lieu en Corée avec une source primaire suffisamment solide pour être consignée — et l’archive préfère publier un petit nombre honnête plutôt que de gonfler la page d’un pays avec des événements survenus chez les clients d’une entreprise coréenne ailleurs.

Comment interpréter les niveaux de confiance avant d’en citer un

Le niveau de confiance concerne la qualité de la source, pas la gravité, et une note D ne signifie pas que c’est faux — elle signifie que les parties ne sont pas d’accord et que vous ne devez pas citer un seul camp. La note A désigne une source primaire : le fournisseur, la victime, les forces de l’ordre ou un rapport officiel. La note B désigne un laboratoire de recherche ou un grand média avec des détails vérifiables. La note C désigne uniquement de la seconde main. La note D signifie que les faits ou l’attribution sont contestés. Sur 302 des 354 enregistrements, la note A représente 85 % du jeu de données, ce qui est inhabituellement élevé pour la déclaration d’incidents et découle directement de la règle « pas de source, pas d’entrée ».

Les réserves honnêtes méritent d’être énoncées clairement, car l’archive les indique. Deux enregistrements restent de classe C et trois de classe D. Quatre-vingt-cinq enregistrements portent une sévérité informative, car ce sont des entrées de politique ou de rapport de menace conservées pour la continuité de la chronologie, et non des incidents. Le dépôt a trois semaines et ne comporte aucune étoile, aucune version publiée et aucun audit externe de sa propre méthodologie — il s’agit d’un jeu de données publié ouvertement, et non d’une étude évaluée par les pairs.

Pourquoi c'est plus important qu'un autre benchmark

À mesure que les agents acquièrent des navigateurs, des shells, des identifiants, des capacités d’exécution de code et un accès à la production, la question de sécurité cesse d’être de savoir ce dont un modèle est capable et devient de savoir ce qui a déjà été fait avec l’un d’eux. Les benchmarks répondent bien à la première question, et pas du tout à la seconde. Une archive d’incidents, évaluée selon la qualité des sources et filtrée selon que quelqu’un a réellement subi un préjudice, est le seul type d’instrument qui répond à la seconde — et elle ne fonctionne que si les entrées sont traçables, corrigibles et libres de réutilisation.

Voilà ce qui est désormais ouvert. Le jeu de données se trouve sur a href="https://www.orcarouter.ai/incident-archive">orcarouter.ai/incident-archive/a>, le Markdown brut, les exports JSON et CSV et le schéma se trouvent dans le a href="https://github.com/Continuum-AI-Corp/Orca-AI-Incident-Archive">dépôt public/a>, et les corrections passent par l'historique de révision de l'enregistrement. Si vous connaissez un événement qui y a sa place, le parcours de contribution se résume à un fichier Markdown et à au moins une source. Pas de source, pas d'entrée.

OrcaRouter, qui publie l'archive, exploite un point de terminaison unique compatible OpenAI sur plus de 200 modèles, sans majoration sur les tarifs des fournisseurs et avec un basculement automatique entre eux — la même couche de routage qui permet de pointer un agent vers un modèle moins cher pour les appels faciles et vers un modèle plus puissant pour les appels difficiles, ce qui correspond exactement à l'architecture dans laquelle la plupart des incidents ci-dessus ont été constatés.