В реестре инцидентов с агентами (Agent Incident Registry, AIR) содержится 529 подтвержденных инцидентов с участием ИИ-агентов. В 200 из них агент нанес реальный ущерб реальной стороне. Остальные 329 были выявлены в ходе исследований, тестирования или раскрытия информации до того, как агент успел причинить вред.
Часто обе формы инцидентов с ИИ-агентами собираются в одни и те же списки. Агент, который действительно удалил данные, раскрыл информацию или стал причиной финансовых потерь, учитывается так же, как и исследователь, доказавший, что агента можно обмануть. Оба случая стоит отслеживать, но они говорят о разных рисках.
Реестр Agent Incident Registry был создан для того, чтобы разделять эти инциденты. Это различие важно для всех, кому нужно знать, описывает ли конкретный инцидент реальный ущерб или демонстрацию того, что возможно в принципе.
Почему одинаковый подсчет всех инцидентов создает проблемы
Большинство публичных систем отслеживания инцидентов ИИ не предназначены специально для агентов. Они охватывают широкий спектр вреда, связанного с ИИ, что логично для их целей. Но агент создает иную проблему безопасности, поскольку он может действовать на основе того, что генерирует. У него может быть доступ к браузеру, репозиторию кода, 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 помечает его как «средний уровень достоверности». Если зацепку невозможно проверить, она не публикуется.
Каждому инциденту также присваивается один из четырех классов:
- В дикой природе (In the wild): агент действовал вне рамок теста, проводимого исследователями.
- Сбой безопасности (Safety failure): агент вызвал проблему без участия злоумышленника.
- Раскрытая уязвимость (Disclosed vulnerability): недостаток, о котором сообщили до того, как он причинил вред.
- Исследовательская демонстрация (Research demo): доказательство концепции, проведенное против действующей системы.
Эти классы описывают, как именно проявился инцидент. Они не определяют, пострадал ли кто-то: инцидент «в дикой природе» может произойти без причинения ущерба, а исследовательская демонстрация может иметь реальные последствия. Вот почему AIR отслеживает класс отдельно от реализованного ущерба.
Находите инциденты, соответствующие вашей среде
Реестр из 529 инцидентов бесполезен, если вам нужно прочитать все 529, чтобы найти те несколько, которые применимы к вашим системам. Фильтруйте по классу, области риска, поверхности атаки, уровню автономности и поставщику, чтобы сузить поиск. Если вы развертываете браузерные агенты, сосредоточьтесь на инцидентах, связанных с браузером. Если вы оцениваете агентов для написания кода с доступом к репозиториям и инструментам разработчика, сузьте поиск до этой среды.
Каждое отфильтрованное представление получает свой собственный URL, которым можно поделиться, поэтому вы можете отправить конкретный набор инцидентов инженеру, команде безопасности, аудитору или комитету по рискам вместо всей базы данных.
Каждая запись показывает доступ, который был у агента, инструмент, который он вызвал, ввод, который его спровоцировал, и сработала ли защита. Этого достаточно для того, чтобы выстраивать защиту, а не просто читать об этом.
Каждый инцидент получает постоянный ID
Инциденты с ИИ-агентами все чаще упоминаются в научных статьях, реестрах рисков, ответах на аудиты, материалах для советов директоров, анкетах страховых компаний и стандартах. Проблема в том, что ссылкой обычно является новостная статья, пост в блоге или ветка в социальных сетях. Эти источники могут измениться или исчезнуть, некоторые оказываются за платным доступом, а два отчета об одном и том же инциденте могут описывать его настолько по-разному, что невозможно понять, что речь идет об одном и том же событии.
AIR присваивает каждому инциденту постоянный идентификатор в формате AIR-YYYY-NNNN. ID присваивается один раз и никогда не меняется, а каждая запись имеет постоянную ссылку, которой можно поделиться.
Думайте об этом как о CVE для инцидентов с агентами. Стабильная ссылка, которую можно вставить в статью, отчет, аудит или реестр рисков, зная, что в следующем году она будет указывать на ту же самую подтвержденную запись.
Каждая запись также сопоставлена с областями риска из таксономии рисков агентов Enkrypt AI, опубликованной в Black-Box Red Teaming of Agentic AI. Если вы используете эту таксономию, AIR связывает ее категории с задокументированными инцидентами.
Полная методология, система классификации и выводы описаны в The Agent Incident Registry: Toward Preventing Repeated AI Agent Failures.
Помогите дополнить реестр
Подобный реестр наполняется только в том случае, если компании продолжают публиковать информацию о том, что пошло не так. Если вы обнаружили или раскрыли инцидент с ИИ-агентом, отправьте его вместе с подтверждающим источником. Мы получаем источник, сохраняем дословную цитату, классифицируем инцидент с использованием таксономии и присваиваем AIR ID, используя тот же процесс, который применяется к каждой существующей записи.
- Просмотреть реестр
- Отправить источник
Enkrypt AI, часть Anaconda, создает возможности безопасности и защиты ИИ в платформе Anaconda Platform и поддерживает реестр инцидентов с агентами (Agent Incident Registry) в качестве публичного ресурса.
FAQ
Реализованный вред означает, что реальная сторона понесла реальные последствия из-за ИИ-агента. Исследователь, демонстрирующий, что он может это сделать, фиксируется, но никогда не считается вредом. Из 529 записей 200 документов подтверждают реализованный вред.
Как сослаться на инцидент с ИИ-агентом? Каждая запись имеет вид AIR-ГГГГ-НННН, создается один раз и никогда не перенумеровывается. Каждый идентификатор имеет постоянную ссылку.
Как инцидент попадает в реестр? Ничего не пишется по памяти. Для записи требуется полученный подтверждающий источник и процитированное из него предложение. Доказательства только из вторичных источников помечаются как имеющие среднюю степень достоверности, а непроверяемые сведения помещаются в карантин.
Что представляют собой четыре класса? «В дикой природе», «отказ системы безопасности», «раскрытая уязвимость» и «исследовательская демонстрация». Класс фиксирует, как событие стало известно, независимо от реализованного вреда. Попытки атак «в дикой природе» и инциденты, близкие к нарушению безопасности, могут остаться нереализованными, а исследования на действующих системах все равно могут иметь последствия.
Почему количество инцидентов варьируется в зависимости от источников? Подсчеты отслеживают тех, кто публикует информацию, а не тех, на кого совершаются атаки. Поставщики со зрелыми программами раскрытия информации появляются чаще именно потому, что их выводы являются публичными.
