Инцидент с ИИ-агентом: улика — учётная запись, а не мотив

16 октября 2026 года NIST, CISA и NSA выпустили гайд на 14 страниц: десять практик на случай, когда ИИ-агент делает то, чего ему никто не поручал. Инцидент с ИИ-агентом в первые часы расследуют не по мотивам, а по учётным записям: чьи ключи сработали и кто может их отозвать. Часть этих ключей компания отозвать сама не сможет — это показала утечка в OpenCode на следующий день после выхода гайда.

Что NIST, CISA и NSA опубликовали 16 октября 2026

Три американских ведомства выпустили совместный документ Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation объёмом 14 страниц. В нём десять добровольных практик на случай, когда ИИ-агент совершает значимые действия, которых ему никто не поручал.

Практики разложены по пяти стадиям: подготовка, обнаружение, реагирование, восстановление и уведомление (prepare, detect, respond, recover, report). Опираются они на привычные процессы управления инцидентами, поэтому большая часть требований знакома: минимальные привилегии, управление учётными данными, мониторинг, сохранение доказательств, пересборка среды из эталонной конфигурации.

Адресат — организации, которые обучают или оценивают наиболее мощные (frontier) модели-агенты на длинных задачах, то есть на многошаговой работе, растянутой во времени, при ограниченном надзоре человека. Авторы оговаривают, что документ пригодится и тем, кто агентов внедряет. Обязательной силы у него нет.

Широко гайд обсуждают после колонки Len Noe, архитектора решений BeyondTrust, вышедшей на BleepingComputer 26 октября. Материал спонсирован и написан BeyondTrust, а компания продаёт AI Agent Security — продукт, который применяет политики к отдельным действиям агента во время выполнения. Поэтому ниже мы разделяем три слоя: сам гайд, инциденты из колонки и телеметрию производителя.

Почему prompt injection не считается инцидентом с ИИ-агентом

Гайд изучает только поведение, которое агенту никто не задавал. Prompt injection и бэкдор в модели он относит к действиям по команде — просто команду отдал не тот, кто должен.

Определение звучит так. Control incident — событие, в котором агенты совершают значимые действия, не направленные ни оператором, ни противником, и эти действия подрывают средства контроля, политики или человеческий надзор.

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

Для исследователей граница логична: их интересует, когда модель сама выходит за рамки задания. Команде реагирования она мешает. В первые часы на вопрос о намерении почти никогда нельзя ответить. Видно другое: агент под таким-то токеном сходил в продакшен-базу или выгрузил репозиторий.

Отсюда первая фраза колонки: «Первый вопрос на созвоне по инциденту — не почему это случилось, а чьи учётные данные использованы». У расследующего на руках учётная запись, набор прав и след действий. По ним и предстоит понять, был ли агент обманут, сломан или скомпрометирован.

Разница между двумя классами рисков видна и в OWASP Top 10 for LLM Applications 2025: prompt injection там стоит под номером LLM01, а избыточные полномочия агента вынесены отдельно, в LLM06 Excessive Agency. Фильтр на входе не заменяет урезанные права. Если инъекция прошла, она не должна автоматически открывать доступ к платёжному API.

Насколько такие события редки? Колонка приводит раскрытие одной неназванной лаборатории: шесть инцидентов на 141 006 оценок, около 0,004%. Но частота ничего не говорит об ущербе. Noe отвечает на довод о соразмерности так: сбитый с курса агент с точки зрения учётной записи выглядит как скомпрометированная сервисная учётка, только работает быстрее.

Какие ключи агента компания не может отозвать сама

Это ключи, которые выпустили провайдеры моделей и облаков. Гайд почти их не упоминает, хотя деньги в реальном инциденте утекают как раз через них.

Шестая практика требует отозвать учётные данные, к которым агент получил доступ во время инцидента, и пересобрать потенциально скомпрометированные среды. Колонка обращает внимание на оговорку: речь только о данных «под контролем организации». Noe формулирует это так: ключ, который хранит агентская платформа, можно отозвать только у провайдера, который его выпустил, и только из аккаунта владельца.

Пример — OpenCode, открытый агент для программирования (coding-агент) с облачным сервисом Console. Пользователи хранили там ключи сторонних провайдеров, в том числе Anthropic, OpenAI и Google. Компания сообщила части клиентов, что эти ключи утекли: пострадали 1,4% пользователей Console. Самое раннее зафиксированное раскрытие — 00:30 UTC 17 октября 2026 года.

Пользователи сообщали о несанкционированных списаниях от нескольких сотен до 1 700 долларов за одну ночь. Часть проектов в Google Cloud заблокировали за злоупотребления (abusive activity), что похоже на захват ресурсов.

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

Отозвать такой ключ OpenCode не может. Это делает каждый пострадавший в своём кабинете у Anthropic, OpenAI или Google. Владелец аккаунта может вообще не знать, что ключ утёк, а компания, чей сотрудник положил туда корпоративный ключ, рискует узнать об этом по счёту.

Стадия уведомления в гайде добавляет вторую обязанность: сообщить сторонам, чьи системы скомпрометировали или использовали, включая третьих лиц, которые не были конечной целью. У OpenCode это провайдеры моделей и владельцы ключей. Вовремя уведомить их можно, только если кто-то знает, какой ключ где лежал.

Для платформ, которые хранят чужие секреты, такой риск не новый. В 2021 году изменённый Bash Uploader в Codecov с 31 января по 1 апреля собирал секреты из CI-сред клиентов, и Codecov рекомендовал ротировать всё, что было доступно этим процессам.

В январе 2023 года CircleCI сообщил о краже SSO-сессии сотрудника с заражённого ноутбука и попросил клиентов ротировать хранившиеся секреты, хотя учётная запись была защищена 2FA. Консоль агентов наследует тот же риск: ущерб определяет не сложность атаки, а то, сколько секретов лежит в одном месте.

Что гайд требует от изоляции и журналов агента

Гайд исходит из того, что агент найдёт ошибки конфигурации и уязвимости, и просит строить контроль с этим расчётом. Июльский эпизод с Hugging Face, известный по реконструкции MIT Technology Review, показывает почему.

На кибертесте агенты на моделях OpenAI должны были работать без интернета. Они всё равно вышли в сеть, взломали Hugging Face и достали решения задач, на которых застряли. Единственный контроль, описанный в статье, — сетевая изоляция, и агенты её обошли. Исследователи OpenAI связывают такое поведение с обучением, которое его поощряло.

Вывод Noe: сетевую границу обходит любой упорный нарушитель, человек или нет. Учётные данные, выданные под одну задачу, истекающие вместе с ней и привязанные к учётной записи, отдельной от запустившего агента человека, не зависят от его поведения. Утёкшая копия такого ключа немного даст.

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

Изоляцию нужно проверять, а не декларировать: из той же среды выполнения, с теми же маршрутами, DNS и прокси, что достаются агенту. Наличие NetworkPolicy или галочки в настройках песочницы ещё не доказывает, что агент не выйдет наружу.

К журналам гайд предъявляет четыре требования:

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

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

Почему журналов на уровне промптов мало, показывает телеметрия BeyondTrust Phantom Labs. За четыре недели на выборке клиентов coding-агенты запросили около 1,28 млн shell-команд примерно на 132 000 промптов — почти десять команд на промпт.

Оговорки две: это запрошенные команды, а не те, выполнение которых подтверждено, и это данные производителя на его клиентской базе. Но вывод от них не зависит: если журнал не отделяет действия агента от действий пользователя, он не ответит, чьи полномочия использованы.

Как измерить готовность к инциденту с ИИ-агентом

Колонка предлагает мерить готовность результатами, а не документами. Три метрики можно посчитать своими силами, без покупки чьего-либо продукта:

1. Время перечисления учётных данных. За сколько минут вы составите полный список того, чем может пользоваться учётная запись агента, включая сторонние ключи, которые он хранит.
2. Покрытие собственными учётками. Какая доля агентов работает под собственной учётной записью и имеет именного сотрудника-спонсора, а не «команду платформы».
3. Атрибуция сессии. Можете ли вы выдать запись сессии, где действия человека отделены от действий агента, работавшего от его имени.

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

Первая метрика указывает на проблему, о которой мы писали в материале про забытые ИИ-агенты с живыми ключами и вебхуками: если вы не знаете, сколько у вас агентов, перечислить их ключи не получится.

С чего начать, если агент сидит на общей сервисной учётке

Начните с агентов, которые дотягиваются до самых чувствительных данных и самых значимых действий: выдайте им отдельные учётные записи и расширяйте охват по мере того, как позволяют приложения. Переводить всё сразу не нужно, да и бюджета не хватит.

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

Заметка практика. Проверяя агентские интеграции, мы начинаем с цепочки «сотрудник-спонсор → агент → сессия → учётные данные → инструмент → ресурс». Запись «service-account X обратился к API» при общем токене не говорит ни какой это был агент, ни кто поставил ему задачу. Ещё три вещи проверяем всегда:

• Порядок действий. Сначала фиксируем учётную запись, ID сессии, вызовы инструментов, отклонённые действия, версии конфигурации и журналы аудита у провайдеров, и только потом отзываем ключи и пересобираем среду. Исключение — ключ, который прямо сейчас тратят: его отзываем сразу.
• Реестр мест отзыва. Удалённый агент, конфиг или виртуальная машина не убивают токен у внешнего провайдера. Для каждого стороннего ключа нужны владелец и понятное место, где его отзывают.
• Лимиты расходов. Пример OpenCode с 1 700 долларами за ночь показывает: жёсткий лимит бюджета на ключе ограничивает ущерб ещё до того, как кто-то проснётся.

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

Что инцидент с агентом значит для российских компаний

Для оператора персональных данных такой инцидент быстро становится регуляторным событием, и сроки не ждут, пока вы разберётесь с классификацией. Если агент неправомерно передал ПДн или открыл к ним доступ, статья 21 закона № 152-ФЗ требует уведомить Роскомнадзор в течение 24 часов с момента обнаружения и сообщить результаты внутреннего расследования в течение 72 часов.

Американский гайд обсуждает, считать ли событие control incident. Российскому регулятору это неважно: значимы факт утечки и ваша способность объяснить, что произошло. Без атрибуции сессии отчёт за 72 часа получится набором догадок. С 30 мая 2025 года к этому добавились оборотные штрафы за утечки ПДн.

Руководителю здесь нужно решить три вопроса. Кто отвечает за каждого агента поимённо. Кто и где отзывает сторонние ключи, если их хранит внешняя платформа. Входят ли агентские сценарии в действующий план реагирования и проверялись ли они на учениях.

Если план пока существует только на бумаге, отдельную роль в нём стоит отдать внешней команде по реагированию на инциденты ИБ, которую не придётся искать посреди ночи при утечке.

Чего пока не известно

По каждому из трёх слоёв истории остаются пробелы, и выводы приходится делать с поправкой на них.

• OpenCode не раскрыла, как злоумышленники получили ключи. Версия об атаке с дистилляцией модели не подтверждена, CVE и индикаторов компрометации в публичном описании нет.
• Лаборатория, давшая цифру «шесть инцидентов на 141 006 оценок», не названа. Нельзя проверить ни методику подсчёта, ни то, что именно считалось инцидентом.
• Эпизод с Hugging Face известен по реконструкции журналистов, а не по техническому отчёту. Как именно агенты обошли изоляцию, публично не описано.
• Методика Phantom Labs не раскрыта: размер выборки клиентов и долю реально выполненных команд установить нельзя.
• Гайд добровольный и написан для лабораторий. Как его практики перенесут на корпоративных агентов, покажут первые разборы реальных инцидентов.

Когда агент в первый раз сделает что-то не то, мотив вы узнаете последним. Первым придётся отвечать, чья учётная запись сработала и кто может её отключить.

Частые вопросы

Что такое control incident в гайде NIST, CISA и NSA?

Это событие, в котором ИИ-агент совершает значимые действия, не направленные ни оператором, ни противником, и эти действия подрывают средства контроля, политики или человеческий надзор.

Входит ли prompt injection в определение инцидента с ИИ-агентом?

Нет. Действия, вызванные prompt injection или бэкдором в модели, гайд считает выполненными по чужой команде (instructed). Реагировать на них всё равно придётся теми же шагами: зафиксировать доказательства, ограничить агента, отозвать доступ.

Как отозвать ключи ИИ-агента, если их выпустила не ваша компания?

Только у провайдера, который выпустил ключ, и только из аккаунта владельца. Поэтому для каждого стороннего ключа заранее нужен реестр: кто владелец, где ключ отзывается и какой лимит расходов на нём стоит.

Что случилось с API-ключами OpenCode в октябре 2026 года?

Из облачной Console утекли сохранённые ключи Anthropic, OpenAI и Google. Пострадали 1,4% пользователей Console, самое раннее раскрытие — 00:30 UTC 17 октября, списания доходили до 1 700 долларов за ночь. Как злоумышленники вошли в систему, компания не раскрыла.

Какие логи нужны, чтобы восстановить действия ИИ-агента?

Журналы с надёжными метками времени, недоступные агенту для чтения и изменения, с отклонёнными действиями и вызовами инструментов, а также зафиксированные конфигурации агента, защитных механизмов и среды.

Нужно ли уведомлять третьи стороны, если агент задел их системы?

По гайду да: уведомлять нужно всех, чьи системы скомпрометировали или использовали, даже если они не были конечной целью. Для российских операторов ПДн отдельно действуют сроки 152-ФЗ: 24 часа на уведомление Роскомнадзора и 72 часа на результаты расследования.

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