Архив инцидентов Orca AI: 354 реальных инцидента с ИИ-агентами, каждый — с подтверждением

Команда безопасности может точно сказать, насколько хорошо модель сопротивляется промпт-инъекциям внутри тестового стенда. Чего почти никто не может сказать — это сколько организаций на самом деле подверглись взлому со стороны агента в прошлом месяце, в каких из этих инцидентов была подтверждённая жертва и какие из цифр, приведённых в отчёте, взяты у поставщика, а не у регулятора. Этот разрыв — между тем, что модели могут сделать, и тем, что уже произошло, — и есть тот разрыв, который a href="https://www.orcarouter.ai/incident-archive">Orca AI Incident Archive/a> был создан, чтобы закрыть. Он заработал 23 сентября 2026 года и по состоянию на срез данных от 22 сентября содержит 354 записи, собранные из 593 уникальных источников.

Примечание о точности: все приведённые ниже цифры взяты из собственного опубликованного архивом code>dist/stats.json/code> версии 2026-09-22 и с актуальной страницы. В анонсе запуска 23 сентября упоминались 340 записей, 548 источников и 126 с подтверждённым вредом; это были цифры на момент публикации, а архив обновляется непрерывно, поэтому два набора различаются примерно на сутки поступления данных. Там, где README архива и его актуальная страница расходились в номере бейджа во время разработки, следует доверять актуальной странице и экспорту JSON.

Что на самом деле содержит архив

Это не новостная лента и не список CVE. Каждая запись — это отдельный Markdown-файл со структурированным frontmatter, отнесённый к месяцу, в котором произошло событие, и каждая запись содержит как минимум один источник. Набор данных опубликован под лицензией CC BY 4.0 и зеркалируется в публичном репозитории, поэтому всё это можно клонировать, сравнивать с помощью diff и цитировать, а не делать скриншоты.

Период покрытия составляет 22 месяца — с предвестника в декабре 2024 года по 22 сентября 2026 года, и самое интересное здесь — это распределение. По уровню серьёзности: 45 критических, 139 высоких, 77 средних, 8 низких и 85 информационных. По достоверности источника: 302 класса A, 47 класса B, 2 класса C и 3 класса D. Подтверждённый реальный ущерб зафиксирован для 127 записей, явно исключён для 142, а для 85 оставлен null.

Эти последние три числа — причина, по которой архив стоит читать внимательно, а не пробегать глазами. Число в 354 записи — это не число 354 инцидентов. Только 138 из них вообще классифицируются как инцидент; остальные — это раскрытия уязвимостей, демонстрации исследований, отчёты об угрозах и политические шаги. Именно подсчёт всех пяти категорий вместе и приводит к неверной цифре для заголовка — вот почему архив хранит их раздельно и позволяет фильтровать.

Почему «джейлбрейк — это не инцидент» — в этом вся суть

Большинство подборок событий в области безопасности ИИ стирают одно различие: агент, который действительно причинил ущерб, — не то же самое, что исследователь, показавший, что он мог его причинить. Именно это отождествление превращает демонстрацию на конференции в заголовок о взломе, и именно это архив и создан отвергать.

Три поля несут эту нагрузку. code>real_harm/code> фиксирует, был ли подтверждён пострадавший. code>ai_involvement/code> фиксирует, подтвердил ли первоисточник — поставщик, пострадавший, правоохранительные органы или официальный отчёт — роль ИИ, при этом спорные атрибуции остаются в наборе данных, но помечаются. code>kind/code> фиксирует, какого типа документ представляет собой запись. Запись без источника в набор не попадает. Запись с противоречивыми доказательствами помечается как спорная, а не разрешается в ту сторону, которая читается лучше. Когда поступают новые доказательства, запись обновляется, а изменение вносится в её историю изменений, а не перезаписывается молча.

Архив применил это правило к самому себе. В ходе собственных проверок он удалил две записи, которые не удалось подтвердить, исправил широко растиражированное утверждение о том, как быстро развивалось одно вторжение, и понизил степень достоверности третьей записи, когда лежавшие в её основе доказательства оказались получены из вторых рук. База данных инцидентов, из которой никогда ничего не удаляли, — это база данных, которую не проверяли.

Двенадцать поверхностей атаки, по которым он сортирует

Каждая запись помечена одним или несколькими из двенадцати типов, и для каждого типа ведётся собственный помесячный подсчёт. «Управление и политика» — самая крупная категория: 65 записей, но лишь в одной из них подтверждён вред, — что является правильной формой для регуляторной активности и вводит в заблуждение, если цитировать это как число инцидентов. Далее идёт «Злоупотребление учётными данными» — 55, с 40 подтверждёнными пострадавшими, наивысшей плотностью вреда в наборе. «Агент как оружие» занимает 51 позицию с 28 подтверждёнными. У «Косвенной инъекции промпта» 45 записей, но лишь 5 с подтверждённым вредом, — это самое наглядное проявление разрыва между возможностями и последствиями во всём наборе данных: это наиболее изученный класс атак и один из наименее результативных в реальных условиях. «Отравление цепочки поставок» — 36 записей — имеет 27 подтверждённых пострадавших, худшее соотношение в таблице.

Сентябрь 2026 года — это месяц, который служит доказательством.

Только за сентябрь 2026 года было зафиксировано пятьдесят одна запись — более чем вдвое больше, чем в любом предыдущем месяце рассматриваемого периода. Это не внезапный обвал безопасности. Это месяц, в котором учёт наконец догнал год накопленных событий, и значение имеет состав: критические записи о вредоносном code>.git/config/code>, который исполняет код злоумышленника в семи агентах для программирования ещё до того, как происходит обращение к модели; об уязвимости Langflow, эксплуатируемой в реальных атаках; о кампании роя ИИ-агентов у поставщика решений для управления печатью; и о npm-черве, который проникает в цепочку поставок на уровне вышестоящих зависимостей. Рядом с ними стоят информационные записи о стандарте OWASP Agent Control Standard, послании о положении Союза в ЕС, где упоминались случаи выхода агентов из-под контроля, и кратком брифинге панели ООН, в котором один инцидент расценивался как предупреждение о потере контроля.

Корейские записи и что не означает поле региона

Поле архива code>region/code> указывает, где событие фактически произошло, а не где находится головной офис поставщика — трансграничные раскрытия поставщиков всегда классифицируются как глобальные, поэтому 291 из 354 записей не имеют тега отдельной страны. Две записи имеют тег KR, обе — записи о политике с источниками уровня A и без подтверждённого вреда: удаление DeepSeek из южнокорейских магазинов приложений в апреле 2025 года и общекорпоративный запрет на OpenClaw, принятый Naver, Kakao и Karrot в феврале 2026 года.

Эта сдержанность намеренна. Количество по региону, равное двум, — это не утверждение, что в Корее произошло два события в области безопасности ИИ. Это утверждение, что два события в этом временном окне попали в Корею, причём с первоисточником, достаточно надёжным для внесения в архив, — и архив скорее опубликует небольшое честное число, чем станет раздувать страницу страны событиями, которые произошли с клиентами корейской компании где-то в другом месте.

Как читать оценки уверенности, прежде чем ссылаться на одну из них

Достоверность отражает качество источника, а не серьёзность, и оценка D не означает ложь — она означает, что стороны расходятся во мнениях и не следует ссылаться только на одну сторону. Оценка A означает первичный источник: поставщик, пострадавший, правоохранительные органы или официальный отчёт. Оценка B означает исследовательскую лабораторию или крупное издание с проверяемыми подробностями. Оценка C означает, что информация получена только из вторых рук. Оценка D означает, что факты или атрибуция оспариваются. 302 из 354 записей имеют оценку A — это 85% набора данных, что необычно много для отчётности об инцидентах и является прямым следствием правила «нет источника — нет записи».

Честные оговорки стоит изложить прямо, потому что архив их приводит. Две записи остаются класса C, а три — класса D. Восемьдесят пять записей имеют информационный уровень серьёзности, поскольку это записи о политике или отчётах об угрозах, сохранённые для непрерывности хронологии, а не инциденты. Репозиторию три недели, у него нет звёзд, релизов и внешнего аудита его собственной методологии — это открыто опубликованный набор данных, а не рецензируемое исследование.

Почему это важнее, чем очередной бенчмарк

По мере того как агенты получают браузеры, оболочки, учётные данные, возможность выполнения кода и доступ к производственной среде, вопрос безопасности перестаёт быть вопросом о том, на что способна модель, и становится вопросом о том, что уже было сделано с её помощью. Бенчмарки хорошо отвечают на первый вопрос и совсем не отвечают на второй. Архив инцидентов, оценённый по качеству источников и отфильтрованный по тому, был ли кто-то реально пострадавшим, — единственный инструмент, который отвечает на второй, — и он работает только в том случае, если записи прослеживаемы, исправляемы и свободны для повторного использования.

Вот что теперь открыто. Набор данных находится по адресу a href="https://www.orcarouter.ai/incident-archive">orcarouter.ai/incident-archive/a>, исходный Markdown, экспорты JSON и CSV, а также схема находятся в a href="https://github.com/Continuum-AI-Corp/Orca-AI-Incident-Archive">публичном репозитории/a>, а исправления проходят через историю изменений записи. Если вы знаете о событии, которое должно быть в нём, путь для внесения — один файл Markdown и как минимум один источник. Нет источника — нет записи.

OrcaRouter, публикующий этот архив, обслуживает единую конечную точку, совместимую с OpenAI, для более чем 200 моделей — без наценки на цены провайдеров и с автоматическим переключением при сбоях между ними; это тот самый слой маршрутизации, который позволяет направлять агента к более дешёвой модели для простых вызовов и к более сильной — для сложных, и именно в такой архитектуре были обнаружены большинство из вышеописанных инцидентов.