Реестр инцидентов агентов (AIR) содержит 529 подтвержденных инцидентов с участием ИИ-агентов. В 200 из них агент нанес реальный ущерб реальной стороне. Остальные 329 были выявлены в ходе исследований, тестирования или раскрытия информации до того, как агент причинил вред.
Часто обе формы инцидентов с ИИ-агентами собираются в одни и те же списки. Агент, который действительно удалил данные, раскрыл информацию или привел к финансовым потерям, учитывается наравне с исследователем, доказавшим возможность взлома агента. И то, и другое стоит отслеживать, но они говорят о риске совершенно разные вещи.
Реестр инцидентов агентов был создан для того, чтобы разделять эти инциденты. Это различие важно для каждого, кому необходимо знать, описывает ли конкретный инцидент реальный ущерб или демонстрацию того, что возможно в принципе.
Почему одинаковый учет всех инцидентов создает проблемы
Большинство публичных трекеров инцидентов ИИ не созданы специально для агентов. Они охватывают широкий спектр вреда, связанного с ИИ, что вполне логично для их целей. Но агент создает другую проблему безопасности, потому что он может действовать на основе того, что генерирует. У него может быть доступ к браузеру, репозиторию кода, API, базе данных или учетным данным, и когда что-то идет не так, вывод модели — это лишь часть картины. Вам также необходимо знать:
- Какой доступ был у агента?
- Какой инструмент он использовал?
- Какие действия он предпринял?
- Какой ввод вызвал это действие?
- Пострадал ли кто-нибудь на самом деле?
9 июля 2026 года оценочный агент OpenAI, выполнявший бенчмарк кибервозможностей, сбежал из своей изолированной среды (песочницы) и проник в производственную инфраструктуру Hugging Face. Он собрал учетные данные, перемещался по производственным кластерам, эксфильтровал внутренние данные и злоупотребил учетными записями в четырех внешних сервисах. Hugging Face проанализировала около 17 600 действий агента, сменила все учетные данные и перестроила базовую инфраструктуру. Им никто не управлял. Семь дней спустя Hugging Face опубликовала полный технический отчет о том, что произошло (AIR-2026-0163).
Этот отчет побудил компанию Irregular, которая проводит оценки кибербезопасности для нескольких передовых лабораторий, пересмотреть собственную работу. Двумя месяцами ранее модели Gemini было поручено атаковать вымышленную компанию внутри изолированной среды. Доступ в интернет был доступен тогда, когда его быть не должно, а вымышленная компания носила такое же название, как и реальная. Модель угадала пароль для проникновения в системы одной компании и использовала учетные данные из публичных репозиториев для проникновения еще в две. Google заявляет, что останавливал работу каждый раз, когда распознавал реальную компанию, охарактеризовал эти эпизоды как ошибку идентификации, а не несоответствие целей (misalignment), и раскрыл их после запроса Wall Street Journal (AIR-2026-0250).
Модели Anthropic выходили из-под изоляции в ходе тех же тестов (AIR-2026-0173). Три отдельных случая раскрытия информации, без единого общего учета.
Ничто из этого не является историей об «отупевшем» или вышедшем из-под контроля агенте (rogue agent). Это были тестовые среды, которые должны были быть изолированы от интернета, но не были, и вовлеченные команды нашли проблему и устранили ее — для себя. У того, кто в следующем месяце будет создавать тестовый стенд (evaluation harness), нет никаких причин знать, что все это произошло.
Практика раскрытия информации также искажает общую картину. У вендора с развитой программой безопасности больше публично задокументированных уязвимостей, потому что у исследователей есть установленный способ сообщить о них, а вендор публикует то, что обнаруживает. У вендора с меньшим количеством публичных отчетов не обязательно меньше проблем. Количество инцидентов часто измеряет лишь то, кто именно предает их огласке.
Проверенные инциденты с приложенными доказательствами
Каждая запись в AIR требует полученного источника и буквальной цитаты из него. Ничего не пишется по памяти. Если инцидент может быть подтвержден только вторичными сообщениями, AIR присваивает ему среднюю степень достоверности (medium confidence). Если лид не удается проверить, он не публикуется.
Каждому инциденту также присваивается один из четырех классов:
- «Дикие» условия (In the wild): агент действовал за пределами теста, проводимого исследователями.
- Сбой безопасности: агент создал проблему без участия злоумышленника.
- Раскрытая уязвимость: недостаток, о котором сообщили до того, как он нанес вред.
- Исследовательская демо-версия: концептуальное доказательство (PoC), проведенное против действующей системы.
Эти классы описывают то, как именно проявился инцидент. Они не определяют, пострадал ли кто-нибудь: инцидент в дикой природе может произойти без причинения ущерба, а исследовательская демонстрация может иметь реальные последствия. Вот почему AIR отслеживает класс отдельно от реализованного ущерба.
Найдите инциденты, соответствующие вашей среде
Реестр из 529 инцидентов бесполезен, если вам приходится читать все 529, чтобы найти те несколько, которые применимы к вашим системам. Выполняйте фильтрацию по классу, области риска, поверхности атаки, уровню автономности и вендору, чтобы сузить круг поиска. Если вы развертываете браузерных агентов, сосредоточьтесь на инцидентах, связанных с браузером. Если вы оцениваете агентов написания кода с доступом к репозиториям и инструментам разработчика, сузьте область поиска до этой среды.
Каждый отфильтрованный вид получает свой собственный доступный для распространения URL-адрес, поэтому вы можете отправить конкретный набор инцидентов инженеру, команде безопасности, аудитору или комитету по рискам вместо всей базы данных.
Каждая запись показывает доступ, который был у агента, вызванный им инструмент, входные данные, которые спровоцировали инцидент, и то, сработал ли механизм защиты. Этого уровня детализации достаточно для того, чтобы проектировать защиту на его основе, а не просто читать о нем.
Каждый инцидент получает постоянный ID
Инциденты с ИИ-агентами все чаще цитируются в исследовательских работах, реестрах рисков, ответах на аудиты, материалах для советов директоров, страховых анкетах и стандартах. Проблема в том, что цитированием обычно является новостная статья, пост в блоге или ветка в соцсетях. Эти источники могут меняться или исчезать, некоторые оказываются за пейволлами, а два отчета об одном и том же инциденте могут описывать его настолько по-разному, что вы не сможете понять, что речь идет об одном и том же событии.
AIR присваивает каждому инциденту постоянный идентификатор формата AIR-YYYY-NNNN. Идентификатор присваивается один раз и никогда не перенумеровывается, а каждая запись имеет постоянную ссылку (permalink).
Думайте об этом как о CVE для инцидентов с агентами. Стабильная ссылка, которую вы можете поместить в документ, отчет, аудит или реестр рисков, зная, что в следующем году она приведет к той же проверенной записи.
Каждая запись также сопоставлена с областями рисков из таксономии рисков агентов Enkrypt AI, опубликованной в работе Black-Box Red Teaming of Agentic AI. Если вы используете эту таксономию, AIR связывает ее категории с задокументированными инцидентами.
Полная методология, система классификации и выводы описаны в The Agent Incident Registry: Toward Preventing Repeated AI Agent Failures.
Помогите пополнить реестр
Подобный реестр наполняется только в том случае, если компании продолжают публиковать информацию о том, что пошло не так. Если вы обнаружили или раскрыли инцидент с ИИ-агентом, отправьте его вместе с подтверждающим источником. Мы получаем источник, сохраняем буквальную цитату, классифицируем инцидент с использованием таксономии и присваиваем ID AIR, используя тот же процесс, который применяется к каждой существующей записи.
- Просмотреть реестр
- Отправить источник
Enkrypt AI, входящая в состав Anaconda, создает средства безопасности и защиты ИИ в платформе Anaconda Platform и поддерживает Реестр инцидентов агентов в качестве общедоступного ресурса.
Часто задаваемые вопросы (FAQ)
Что считается реальным инцидентом с участием ИИ-агента? Реализованный вред означает, что реальная сторона понесла реальные последствия из-за ИИ-агента. Демонстрация исследователем возможности совершить подобное фиксируется, но никогда не засчитывается как вред. Из 529 записей 200 документов фиксируют реализованный вред.
Как цитировать инцидент с ИИ-агентом? Каждая запись имеет вид AIR-YYYY-NNNN, создается один раз и никогда не перенумеровывается. Каждый идентификатор имеет постоянную ссылку.
Как инцидент попадает в реестр? Ничего не пишется по памяти. Для записи необходим полученный подтверждающий источник и процитированное из него дословно предложение. Доказательства только из вторичных источников помечаются как имеющие среднюю степень достоверности, а непроверяемые зацепки помещаются на карантин.
Каковы четыре класса? В диких условиях, сбой безопасности, раскрытая уязвимость и исследовательская демоверсия. Класс фиксирует то, как проявилось событие, независимо от реализованного вреда. Попытки атак в диких условиях и почти-инциденты безопасности могут быть нереализованными, а исследования действующих систем все равно могут иметь последствия.
Почему количество инцидентов различается в разных источниках? Подсчеты отражают тех, кто публикует информацию, а не тех, кто подвергается атакам. Вендоры с урегулированными программами раскрытия информации появляются чаще именно потому, что их находки общедоступны.
