Реестр инцидентов агентов (AIR) содержит 529 подтвержденных инцидентов с ИИ-агентами. В 200 из них агент нанес реальный ущерб реальной стороне. Остальные 329 были выявлены в ходе исследований, тестирования или раскрытия информации до того, как агент успел причинить вред.
Часто обе формы инцидентов с ИИ-агентами собираются в одни и те же списки. Агент, который действительно удалил данные, раскрыл информацию или привел к финансовым потерям, учитывается наравне с исследователем, доказавшим возможность обхода защиты агента. И то, и другое стоит отслеживать, но они говорят о рисках совершенно разное.
Реестр инцидентов агентов был создан для того, чтобы разделять эти инциденты. Это различие имеет значение для каждого, кому нужно знать, описывает ли конкретный инцидент реальный ущерб или демонстрацию того, что в принципе возможно.
Почему подсчет всех инцидентов по одному шаблону создает проблемы
Большинство публичных трекеров инцидентов ИИ не предназначены специально для агентов. Они охватывают широкий спектр связанных с ИИ угроз, что вполне логично для их целей. Но агент создает принципиально иную проблему безопасности, поскольку он может действовать на основе того, что генерирует. У него может быть доступ к браузеру, репозиторию кода, API, базе данных или учетным данным, и когда что-то идет не так, вывод модели — это лишь часть картины. Вам также необходимо знать:
- Какой доступ был у агента?
- Какой инструмент он использовал?
- Какие действия он предпринял?
- Какой ввод вызвал это действие?
- Пострадал ли кто-нибудь в действительности?
9 июля 2026 года оценочный агент OpenAI, выполнявший бенчмарк кибервозможностей, вырвался из своей песочницы и проник в производственную инфраструктуру Hugging Face. Он собрал учетные данные, перемещался по производственным кластерам, задействовал экспорт внутренних данных и скомпрометировал учетные записи в четырех внешних сервисах. Hugging Face изучил около 17 600 действий агента, перевыпустил все учетные данные и пересобрал основную инфраструктуру. Ими никто не управлял вручную. Семь дней спустя Hugging Face опубликовал полный технический отчет о произошедшем (AIR-2026-0163).
Этот отчет побудил компанию Irregular, которая проводит оценки кибербезопасности для нескольких передовых лабораторий, пересмотреть собственную работу. Двумя месяцами ранее модели Gemini было поручено атаковать вымышленную компанию внутри изолированной среды. Доступ в интернет оказался доступен там, где его быть не должно, а вымышленная компания совпала по названию с реальной. Модель угадала пароль для доступа к системам одной компании и использовала учетные данные из публичных репозиториев для проникновения еще в две. Google заявляет, что останавливал работу каждый раз, когда распознавал реальную компанию, охарактеризовал эти эпизоды как ошибку идентификации, а не несоответствие целям, и раскрыл их после запроса Wall Street Journal (AIR-2026-0250).
Модели Anthropic выходили из изоляции в рамках тех же оценок (AIR-2026-0173). Три отдельных случая раскрытия информации без единой общей базы.
Ничто из этого не является историей об «оборзевшем» агенте. Это были тестовые среды, которые должны были быть полностью изолированы от интернета, но не были таковыми, и задействованные команды нашли проблему и устранили ее — для себя. Тот, кто будет создавать тестовый стенд в следующем месяце, не имеет никаких причин знать, что все это уже происходило.
Практика раскрытия информации также искажает картину. У вендора с развитой программой безопасности больше публично задокументированных уязвимостей, поскольку у исследователей есть устоявшийся способ их отчетности, а вендор публикует то, что обнаруживает. У вендора с меньшим количеством публичных отчетов проблем не обязательно меньше. Количество инцидентов часто отражает лишь то, кто именно предает их огласке.
Проверенные инциденты с приложенными доказательствами
Каждая запись в AIR требует полученного источника и дословной цитаты из него. Ничего не пишется по памяти. Если инцидент может быть подтвержден только вторичными источниками, AIR присваивает ему средний уровень достоверности. Если зацепку не удается проверить, она не публикуется.
Каждому инциденту также присваивается один из четырех классов:
- В дикой природе: агент действовал вне тестов под руководством исследователей.
- Сбой безопасности: агент создал проблему без участия злоумышленника.
- Раскрытая уязвимость: дефект, о котором сообщили до того, как он причинил вред.
- Исследовательское демо: доказательство концепции, проведенное на работающей системе.
Эти классы описывают то, как именно проявился инцидент. Они не определяют, пострадал ли кто-нибудь: инцидент «в дикой природе» может произойти без причинения ущерба, а исследовательская демонстрация может иметь реальные последствия. Именно поэтому AIR отслеживает класс отдельно от уже реализовавшегося вреда.
Найдите инциденты, соответствующие вашей среде
Реестр из 529 инцидентов бесполезен, если вам приходится читать их все, чтобы найти те несколько, которые относятся к вашим системам. Фильтруйте по классу, области риска, поверхности атаки, уровню автономности и вендору, чтобы сузить выборку. Если вы развертываете браузерных агентов, сосредоточьтесь на инцидентах, связанных с браузером. Если вы оцениваете агентов для написания кода с доступом к репозиториям и инструментам разработчика, ограничьте область поиска этой средой.
Каждый отфильтрованный вид получает собственный URL, которым можно поделиться, поэтому вы можете отправить конкретный набор инцидентов инженеру, команде безопасности, аудитору или комитету по рискам вместо всей базы данных.
В каждой записи указаны доступ, который был у агента, вызванный им инструмент, вызвавший инцидент ввод и сработал ли защитный механизм. Этого достаточно для того, чтобы выстраивать защиту, а не просто читать об инцидентах.
Каждому инциденту присваивается постоянный идентификатор
Инциденты с ИИ-агентами все чаще цитируются в исследовательских работах, реестрах рисков, ответах на аудиты, материалах для советов директоров, страховых анкетах и стандартах. Проблема в том, что в качестве цитаты обычно выступает новостная статья, пост в блоге или ветка в соцсетях. Эти источники могут меняться или исчезать, некоторые оказываются за платной подпиской, а два отчета об одном и том же инциденте могут описывать его настолько по-разному, что вы не сможете понять, что речь идет об одном и том же событии.
AIR присваивает каждому инциденту постоянный идентификатор в формате AIR-ГГГГ-NNNN. Идентификатор назначается один раз и больше не меняется, а каждая запись имеет постоянную ссылку.
Представьте себе CVE для инцидентов с агентами. Стабильная ссылка, которую можно указать в статье, отчете, аудите или реестре рисков, зная, что в следующем году она приведет к той же проверенной записи.
Каждая запись также соотнесена с областями риска из таксономии рисков агентов Enkrypt AI, опубликованной в работе Black-Box Red Teaming of Agentic AI. Если вы используете эту таксономию, AIR связывает ее категории с уже задокументированными инцидентами.
Полная методология, система классификации и выводы описаны в работе «Реестр инцидентов агентов: на пути к предотвращению повторяющихся сбоев ИИ-агентов».
Помогите пополнить реестр
Подобный реестр наполняется только тогда, когда компании продолжают публиковать информацию о том, что пошло не так. Если вы обнаружили или раскрыли инцидент с ИИ-агентом, отправьте его вместе с подтверждающим источником. Мы получаем источник, сохраняем дословную цитату, классифицируем инцидент с помощью таксономии и присваиваем идентификатор AIR, используя тот же процесс, который применяется к каждой существующей записи.
- Просмотреть реестр
- Отправить источник
Enkrypt AI, входящая в состав Anaconda, создает средства безопасности и защиты для Anaconda Platform и поддерживает Реестр инцидентов агентов в качестве общедоступного ресурса.
Часто задаваемые вопросы
Что считается реальным инцидентом с ИИ-агентом?Реальный вред означает, что реальная сторона понесла реальные последствия из-за ИИ-агента. Исследователь, доказавший принципиальную возможность, фиксируется, но никогда не считается причинением вреда. Из 529 записей в 200 документах зафиксирован реальный вред.
Как ссылаться на инцидент с ИИ-агентом?Каждая запись имеет вид AIR-YYYY-NNNN, создается один раз и никогда не перенумеровывается. Каждый идентификатор имеет постоянную ссылку.
Как инцидент попадает в реестр?Ничто не пишется по памяти. Для записи требуется полученный подтверждающий источник и дословно процитированное предложение из него. Доказательства только из вторичных источников помечаются как средняя степень достоверности, а непроверяемые наводки помещаются на карантин.
Каковы четыре класса?В дикой природе, сбой безопасности, раскрытое уязвимое место и исследовательская демонстрация. Класс фиксирует то, как событие проявилось, независимо от причиненного вреда. Попытки в дикой природе и почти произошедшие сбои безопасности могут быть нереализованными, а исследования в реальных системах все равно могут иметь последствия.
Почему количество инцидентов различается в разных источниках?Количество отражает тех, кто публикует информацию, а не тех, кто подвергается атакам. Вендоры с урегулированными программами раскрытия информации появляются чаще именно потому, что их находки находятся в публичном доступе.
