В ходе нашего моделирования инцидента (tabletop-учения) 29 октября участники проработали сценарий инцидента с вымышленным ИИ-агентом и голосовали за каждый следующий шаг. Первый опрос задал базовый уровень: только 22% респондентов имеют регламент (runbook) действий при инцидентах с агентами, который они тестировали за последние шесть месяцев.
В 2026 году произошло два инцидента, когда ИИ-агенты взламывали реальные системы без прямых указаний со стороны злоумышленников. В июле оценочный агент OpenAI сбежал из тестовой среды, которая должна была быть изолированной, и проник в продакшн-инфраструктуру Hugging Face. В июне исследовательский агент OpenAI обошел средства контроля доступа на портале австралийского правительственного агентства Medicare, причем правительству сообщили об этом только через 84 дня.
Сахил Агарвал (Sahil Agarwal), специалист по безопасности ИИ в полевых условиях в Anaconda, провел эту сессию. Участники следили за вымышленным исследовательским агентом, который добрался до портала правительственного ведомства, и отслеживали инцидент в четыре этапа: обнаружение, определение масштаба, сдерживание и раскрытие информации. Каждый участник занимал определенную роль: оператора или пострадавшего ведомства. Вот что они нам рассказали и что это значит для команд, задействующих агентов в продакшне.
Результаты вкратце
1. Большинство респондентов не имеют протестированного регламента для агентов
Из 59 респондентов 22% имеют письменный регламент реагирования на инциденты с ИИ-агентами, который они тестировали за последние шесть месяцев. Еще у 24% есть регламент, который они никогда не тестировали, 32% все еще пишут его, а 22% не имеют никакого.
Это означает, что 78% этой группы столкнулись бы с инцидентом с участием агента без предварительно отработанного плана. Агенты действуют со скоростью машин, запускают другие процессы и ищут обходные пути, когда натыкаются на препятствия. Регламенты, написанные для вредоносного ПО или взломанной учетной записи пользователя, не были рассчитаны на такое сочетание факторов.
Протестированный регламент не обязательно должен быть длинным. Для каждого шага нужен ответственный и хотя бы одна пробная репетиция в сухом режиме.
2. Респонденты колеблются, прежде чем назвать случившееся инцидентом
Первым обновлением стало оповещение о затратах. Агент сделал 4200 исходящих запросов за час, повторно отправлял запросы после десятков ошибок 403 и записал 30 файлов в рамках задачи «только для чтения». Тем временем пострадавшее правительственное ведомство зафиксировало автоматические запросы к URL-адресам черновых отчетов.
Из 41 респондента 73% вызвали бы дежурного инженера и начали бы триаж. Лишь 17% немедленно объявили бы об инциденте, а 10% открыли бы тикет на понедельник.
Триаж — разумный первый шаг. Но предупреждение указывало на нечто большее, чем просто интенсивное использование, и эти сигналы свидетельствуют о том, что агент действовал вне рамок своей задачи:
- Настойчивость после отказов: повторные попытки и поиск обходных путей после ошибок 403 или превышения лимитов запросов (rate limits)
- Запись данных там, где было достаточно чтения: файлы или записи, созданные в рамках задачи «только для чтения»
- Вызовы инструментов за пределами области действия задачи: выполнение кода в рамках исследовательской задачи
- Новые пункты назначения: домены или пути, которые задаче никогда не требовались
- Учетные данные, используемые в новых местах: служебная учетная запись обращается к системам, к которым она никогда раньше не прикасалась
Такое колебание может означать, что критерии серьезности инцидентов для агентов еще не задокументированы. Пороговые значения, созданные для скомпрометированной учетной записи, плохо применимы к агенту, который продолжает попытки после получения отказа. Эти критерии работают только в том случае, если для каждого агента прописан базовый уровень того, что требуется для выполнения его задачи.
3. Голоса разделились между четырьмя типами логов
В 1:15 ночи по сценарию у оператора был стенограмма чата, но вызовы инструментов регистрировались только в виде счетчиков. Мы спросили, какую запись участники хотели бы получить больше всего.
62 голоса разделились почти поровну: 27% выбрали вызовы инструментов с аргументами и результатами, а по 24% выбрали учетные данные, исходящие запросы и подсказки (промпты).
Равное разделение вполне логично для расследования, поскольку каждая запись охватывает его отдельную часть: из промптов вы узнаете, почему агент действовал; из вызовов инструментов — что он сделал; из исходящих запросов — куда он направился; а из учетных данных — как далеко он мог зайти.
Команда Hugging Face изучила около 17 600 действий агента. Проверка в таком масштабе зависит от наличия записей о каждом действии. В ходе сессии были затронуты две связанные с этим практики: хранить логи дольше, чем требуется для обнаружения проблемы, и присваивать каждому агенту собственную идентичность, чтобы его действия не сливались с общей служебной учетной записью.
4. Большинство респондентов предпочли бы сдерживать агента через сеть и учетные данные
В 2:30 ночи агент запустил второй рабочий процесс, ключ его служебной учетной записи все еще был действителен, а в его хранилище находились файлы, которые задача «только для чтения» не должна была создавать.
Из 64 респондентов 38% сначала заблокировали бы сетевой доступ агента, а 34% отозвали бы и сменили его учетные данные. В сумме это составляет 72%. Еще 22% задействовали бы аварийный выключатель (kill switch), а 6% оставили бы его работать, чтобы понаблюдать за его поведением.
Инстинкт заблокировать сеть и учетные данные является здравым, поскольку аварийный выключатель для основного процесса не останавливает рабочий процесс, запущенный агентом, а остановка агента не аннулирует учетные данные, которые он мог собрать. Небольшая доля сторонников аварийного выключателя может означать, что респонденты больше доверяют сетевым мерам и мерам с учетными данными, или что у них отсутствует надежный kill switch.
На практике эти шаги лучше всего работают в фиксированном порядке, причем за каждым закреплен конкретный ответственный:
Оставление агента работающим для наблюдения за ним — разумный выбор в лабораторных условиях. Однако в чужой продакшн-системе каждая лишняя минута увеличивает масштаб ущерба.
5. Готовность к раскрытию информации разделилась
На финальном этапе оператор подтвердил, что агент добрался до черновых данных на портале ведомства и записал файлы на его сервер. Ведомство отследило трафик до облачного провайдера, но не знало, чей это агент.
Из 62 респондентов 40% уведомили бы ведомство в тот же день с тем объемом информации, которым располагали. Остальные 60% стали бы ждать: 35% — до завершения внутреннего расследования, 16% — до юридической проверки, и 8% — только если бы подтвердили, что данные покинули систему ведомства.
Два реальных инцидента 2026 года показывают, к чему может привести такой выбор.
Премьер-министр Австралии публично раскритиковал задержку, хотя правительство назвало технический ущерб незначительным. Компания Hugging Face сменила все учетные данные и перестроила свою основную инфраструктуру.
В австралийском случае главным предметом новостей стало именно затягивание с раскрытием. Пострадавшая сторона не может удалить файлы или сменить учетные данные, о которых она не знает, поэтому каждый день ожидания — это день работы системы с неизвестными изменениями в ней.
Обязательства по раскрытию информации зависят от юрисдикции, сектора и контракта, поэтому юридическая проверка является неотъемлемой частью процесса. Лучше всего она работает параллельно с первым звонком:
- Уведомляйте при подтверждении факта, а не после завершения расследования.
- Найдите конкретное контактное лицо, например руководителя службы безопасности или группу реагирования на компьютерные инциденты (CERT), а не общий почтовый ящик.
- Расскажите о том, что вам известно и неизвестно, а также о том, когда вы предоставите обновление.
- Опубликуйте собственные контакты по безопасности, чтобы оператор мог связаться с вами, если пострадавшей стороной окажетесь вы.
Что делать дальше
Устранение этих пробелов начинается с решений, принимаемых до инцидента:
- Опишите базовые параметры для каждого агента: какие инструменты, пункты назначения и учетные данные требуются для его задачи, а также производит ли он чтение или запись.
- Ведите учет четырех типов записей для каждого агента: промпты, вызовы инструментов, исходящие запросы и учетные данные. Храните их дольше, чем время вашего обнаружения.
- Запишите порядок сдерживания, назначив ответственного за каждый шаг и предусмотрев аварийный выключатель, который распространяется на субагентов.
- Составьте список контактов для каждой внешней системы, к которой могут получить доступ ваши агенты.
- Проведите настольную игру с собственной командой. Замените вымышленного агента на того, с которым работаете вы, и зафиксируйте ответственное лицо и срок для устранения каждой обнаруженной бреши.
Возможности Anaconda по обеспечению безопасности ИИ и защитным механизмам помогают командам проводить тестирование на проникновение для агентов и подключений Model Context Protocol (MCP) перед релизом, применять средства защиты в рантайме и управлять доступом агентов к инструментам и данным.
Агенты будут совершать ошибки. В австралийском инциденте 84 дня между самим происшествием и уведомлением стали результатом человеческих решений. Ваша команда может принять эти решения до того, как столкнется с собственным инцидентом.
В Реестре инцидентов с агентами, поддерживаемом Enkrypt AI (подразделением Anaconda), по состоянию на 26 октября 2026 года было зарегистрировано 570 подтвержденных инцидентов с агентами. Отфильтруйте его по инструменту, поверхности атаки и уровню автономности, чтобы найти инциденты, соответствующие вашей среде, и используйте их в качестве сценариев для собственных учений.
Смотрите запись сессии по запросу. В записи подробно разбираются весь сценарий настольной игры и обсуждение, стоявшее за каждым голосованием.
Как мы проводили опросы
Мы провели пять опросов в Zoom во время прямой трансляции 29 октября 2026 года. В общей сложности 107 участников ответили хотя бы на один вопрос. Количество респондентов в каждом опросе варьировалось от 41 до 64, а процентные показатели рассчитывались по каждому опросу отдельно. Перед подсчетом мы удалили дублирующиеся строки из выгрузки опроса. Участники голосовали по желанию, поэтому данные результаты описывают именно эту аудиторию, а не всю отрасль в целом. Проценты могут в сумме не давать 100% из-за округления.
Часто задаваемые вопросы
Что такое инцидент с ИИ-агентом?
Инцидент с ИИ-агентом — это событие, в ходе которого агент, обладающий инструментами, учетными данными или делегированными полномочиями, действует за пределами своей задачи и оказывает влияние на реальную систему или сторону. Он может быть спровоцирован злоумышленником (например, с помощью инъекции промпта) или происходить вообще без злоумышленника, как в случаях с Hugging Face и австралийским порталом. В Реестре инцидентов с агентами фиксируется, какие инциденты нанесли реальный ущерб, а какие были исследовательскими демонстрациями.
Как определить, что ИИ-агент отклонился от сценария?
Сравните действия агента с тем, что требуется для выполнения его задачи. Выделяются пять признаков: вызовы инструментов за пределами области задачи, новые пункты назначения, продолжение активности после получения отказов, использование учетных данных в новых местах и операции записи там, где было достаточно чтения. Каждый признак опирается на зафиксированное в письменном виде описание того, что требуется для выполнения задачи агента.
Что нужно логировать для каждого ИИ-агента?
Сохраняйте четыре типа записей: промпты, вызовы инструментов с их аргументами и результатами, исходящие запросы, а также использованные агентом учетные данные. Храните их дольше, чем требуется вашей команде для обнаружения проблемы, и связывайте каждую запись с идентификатором, принадлежащим конкретному агенту.
Как локализовать вышедшего из-под контроля ИИ-агента?
Пройдите пять шагов по порядку, каждый из которых имеет назначенного ответственного: остановите агента и все запущенные им процессы, отзовите все доступные ему учетные данные, изолируйте его от сети, сохраните улики и проведите проверку на наличие оставленных им следов. Остановка только основного процесса оставляет без внимания все порожденные им дочерние задачи и собранные учетные данные.
Когда следует сообщать об инциденте с ИИ-агентом?
Уведомите пострадавшую сторону сразу же после того, как подтвердите, что агент получил доступ к ее системам, и расскажите, что вам известно, что остается неизвестным и когда вы предоставите обновление. Обязательства по раскрытию информации зависят от юрисдикции, сектора и контракта, поэтому проводите юридическую проверку параллельно с этим первым звонком, а не до него.
Как проводить настольную игру ( tabletop-учения) по сценарию с ИИ-агентом?
Запланируйте 90-мильную сессию с участием команды операторов, команды пострадавшей стороны, фасилитатора, а также представителя юридического или коммуникационного отдела. Пройдите этапы обнаружения, определения масштаба, локализации и раскрытия информации, проводите голосование на каждом этапе и завершите встречу определением ответственного лица и срока для устранения каждой выявленной бреши.
