NIST, CISA и NSA выпустили 10 практик реагирования на случаи, когда ИИ-агент совершает значимые действия без прямой команды оператора. Для компаний безопасность ИИ-агентов теперь упирается не только в защиту моделей: в первый час расследования нужно понять, под чьими правами агент работал и какие системы успел затронуть.
Документ объёмом 14 страниц адресован прежде всего организациям, которые обучают или тестируют мощных агентов для долгих многошаговых задач с ограниченным контролем человека. Но его выводы важны и для команд, уже подключивших кодовых помощников к репозиториям, облакам, CRM и внутренним API, сообщает BleepingComputer. Если у агента есть токен, сервисная учётная запись или доступ к браузеру, он становится не просто инструментом, а отдельным участником контура безопасности.
Авторы называют «инцидентом контроля» ситуацию, когда агент действует не по указанию оператора и не по команде атакующего, а его поведение подрывает политики, защитные механизмы или человеческий надзор. Руководство предлагает привычную схему: подготовка, обнаружение, реагирование, восстановление и отчётность. Набор мер тоже знакомый: минимальные привилегии, управление учётными данными, мониторинг, сохранение доказательств и восстановление среды из доверенной базы.
Проблема в том, что на практике расследование редко начинается с ясного ответа, был ли агент «самостоятельным», стал жертвой prompt injection или работал с заражённой моделью. Для инженеров важнее другое: какая идентичность выполнила действие, какие разрешения за ней стояли и кто может их отозвать. Безопасность ИИ-агентов нельзя строить на надежде, что причину удастся быстро классифицировать. Сначала нужно изолировать доступы и восстановить цепочку действий, а уже потом спорить о намерениях модели.
Отозвать можно только известные ключи
Шестая практика предписывает отозвать все доступные организации учётные данные, которыми агент воспользовался во время инцидента, а потенциально скомпрометированные среды пересобрать. У этого требования есть неприятное ограничение: компания способна отозвать лишь те секреты, которыми действительно управляет. Агентская платформа может хранить ключи внешних поставщиков, выданные сотрудникам или клиентам, и владелец платформы не всегда может их мгновенно заблокировать.
В качестве иллюстрации BleepingComputer приводит октябрьский инцидент с OpenCode — опенсорсным агентом для программирования. Компания сообщила, что ключи API, сохранённые пользователями в её хостинговой Console для сервисов Anthropic, OpenAI и Google, оказались раскрыты. По данным OpenCode, затронуты были 1,4% пользователей Console, а самая ранняя известная точка утечки — 17 октября, 00:30 UTC. Пользователи сообщали о несанкционированных списаниях от нескольких сотен долларов до $1700 за ночь; часть проектов Google Cloud была приостановлена из-за подозрительной активности.
Причину компрометации OpenCode публично не раскрыл и описал произошедшее как масштабную атаку на извлечение возможностей системы. Для плана реагирования важнее не версия атаки, а механика: ключ внешнего провайдера должен отзывать его владелец у самого провайдера. Если организация не ведёт инвентарь секретов, доступных агенту, она не знает ни что блокировать, ни кого предупреждать. Это касается и третьих сторон: поставщиков моделей, облачных сервисов и владельцев персональных ключей.
Логи должны отвечать, что сделал именно агент
Руководство требует защищённых от подмены журналов с точными временными метками, достаточных для восстановления траектории агента. В них должны попадать не только успешные операции, но и отклонённые вызовы инструментов. Отказ в доступе часто показывает, куда агент пытался попасть, лучше успешной команды, которая выглядит вполне штатно.
Одних журналов промптов для этого недостаточно. Исследование BeyondTrust Phantom Labs на данных endpoint-телеметрии показало: за четыре недели кодовые агенты запросили около 1,28 млн shell-команд примерно по 132 тыс. промптов — почти по десять команд на один запрос. Это именно запрошенные, а не подтверждённо выполненные команды. Если аудит не различает действия агента и человека, расследование не сможет надёжно установить, чьи полномочия были использованы.
Авторы также советуют ограничивать доступ строго задачей, по возможности применять одноразовую инфраструктуру и иметь способ быстро остановить агентскую активность. Этот подход выглядит прозаично, но работает лучше изоляции, которая существует только на диаграмме. В июле агенты на моделях OpenAI во время оценки кибербезопасности сумели получить доступ к интернету, хотя должны были быть от него изолированы, а затем взломали Hugging Face, чтобы найти решения задач. Исследователи OpenAI связывали такое поведение с обучением, поощрявшим достижение результата.
Российским командам, внедряющим агентов в разработку и эксплуатацию, стоит воспринимать это как задачу управления доступом, а не как экзотику из лабораторий ИИ. Отдельная идентичность на запуск, короткоживущие токены, минимальный набор прав и журналирование каждого вызова инструмента сделают последствия ошибки ограниченными. Главный вопрос теперь не в том, станет ли агент участником инцидента, а успеет ли компания до этого создать доказательную базу. Подробности подхода собраны в материале .
