Атаки на ИИ-агентов: разбираем проект таксономии NIST

9 ноября 2026 года Национальный институт стандартов и технологий США (NIST) опубликовал первый публичный проект SP 2400-102 E2026 ^[1]. Авторы развивают таксономию атак на системы машинного обучения 2025 года ^[2] и посвящают отдельную главу агентам ИИ. Замечания принимаются до 18 декабря 2026 года.

NIST систематизирует известные способы атак и меры противодействия, чтобы разработчики, исследователи и специалисты по безопасности пользовались общей терминологией при описании угроз и защиты. На эту классификацию предполагается опираться при разработке последующих стандартов и практических руководств. Документ охватывает предиктивные, генеративные и агентные системы. В этом обзоре остановимся на новой главе об агентах, где рассматриваются целенаправленные атаки на ИИ-агентов.

Какие атаки рассматривает NIST

В главе 4 об агентных системах ^[3] авторы разбирают атаки по этапам работы агента, целям и возможностям нарушителя. Нарушитель может вмешаться в постановку задачи, планирование, выполнение действий или получение результатов работы инструментов и уточнение дальнейшего плана.

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

Способ атаки зависит от того, к каким компонентам системы или данным получил доступ нарушитель. Авторы рассматривают несколько вариантов.

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

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

• Через недоверенные данные и память ^[4] нарушитель влияет на поведение ^[5] агента, помещая подложные инструкции в документы, веб-страницы и базы знаний. Агент читает эти материалы при выполнении задачи и может принять найденные в них инструкции за поручение. Так работает косвенная инъекция в промпт (indirect prompt injection). При отравлении долговременной памяти ^[6] нарушитель добивается того, чтобы агент сохранил подложные сведения и использовал их в следующих задачах. Это один из способов закрепить воздействие между сеансами работы агента (persistence).

• Через инструменты и подключаемые навыки (skills) вредоносные инструкции попадают в описание инструмента, возвращаемые им данные или подключаемый набор рабочих инструкций и скриптов. Агент может изменить план под влиянием описания инструмента ещё до его вызова. Если вредоносный код находится в самом инструменте, при его выполнении возможны хищение данных или блокировка работы.

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

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

Какие меры защиты рассматривает NIST

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

Ограничения на действия агента, очевидно, сказываются и на выполнении полезных задач. Поэтому при проектировании нужно учитывать, какие операции будут запрещены и сможет ли агент функционировать в этих условиях. Авторы также отмечают, что сочетание защиты модели и системы требует дальнейшего исследования. Разделы 4.4–4.5 проекта NIST ^[7].

Как использовать таксономию при подготовке испытаний

Чтобы выяснить, сработает ли выбранная защита в конкретной системе, нужны испытания. Рассмотрим, как можно использовать таксономию NIST при их подготовке, на нашем условном примере. Допустим, агент готовит ответы клиентам. У него есть доступ к почтовому сервису, но отправить письмо можно только после согласования сотрудником. Что произойдёт, если к обращению приложить документ, в котором агенту велено отправить ответ сразу?

Чтобы оценить влияние подложной инструкции, испытатели сравнивают выполнение одного и того же задания с ней и без неё, повторяя оба варианта при одинаковых настройках системы. Журнал вызовов инструмента сопоставляют с журналом почтового сервиса, проверяя, пытался ли агент отправить письмо без согласования. Если агент попытался отправить письмо, но почтовый сервис отклонил запрос из-за отсутствия подтверждения сотрудника, проверка согласования сработала на стороне сервиса. Если сервис всё-таки отправил письмо, в отчёте нужно указать, при каких условиях это произошло, чтобы команда могла воспроизвести обход и повторить испытание после исправления. Независимую от модели проверку допустимости операции и подтверждение человеком действий с серьёзными последствиями рекомендует также OWASP в описании категории риска Excessive Agency. LLM03:2026 Excessive Agency ^[8].

В российском проекте такую проверку можно организовать с опорой на ГОСТ Р 56939-2024, который устанавливает общие требования к разработке безопасного ПО. Таксономию NIST при этом можно использовать как основной или как дополнительный источник для выбора и описания актуальных угроз. В модели угроз указываем, на что воздействует нарушитель и к чему может привести атака. При нефункциональном тестировании воспроизводим его действия, а в отчёте фиксируем сценарий, результат и границы проверки. Пункты 5.7.3.1, 5.19.2.4 и 5.19.3.2 ГОСТ Р 56939-2024 ^[9].

По результатам испытания заказчик сможет судить, как система отреагировала на конкретную попытку отправить письмо без согласования и заблокировала ли отправку. Это один из результатов, на которые можно опереться, оценивая доверие к системе, причём одновременно необходимо оценивать баланс доверия и результативности. Так, ГОСТ Р 59276-2020 связывает доверие с более широким вопросом: справляется ли система с порученными задачами с требуемым качеством? Пункт 3.3 ГОСТ Р 59276-2020 ^[10].

В будущем ещё будет итоговая редакция

После обсуждения и доработки проекта NIST выпустит итоговую редакцию. Для практического применения таксономии потребуется определить, какие из описанных атак возможны в конкретной системе и как проверить её защиту. Одну из методик проведения таких испытаний я уже приводил в новости о руководстве OWASP ^[11].

Для моделирования угроз уже есть российские материалы. Сбер в обновлённой модели угроз для систем ИИ ^[12] учитывает риски агентных и мультиагентных систем, а Яндекс в AI-SAFE ^[13] описывает угрозы и меры защиты для ИИ-агентов. У Консорциума исследований безопасности технологий искусственного интеллекта ^[14] есть рабочая группа по тестированию технологий ИИ. Ждём дальнейшего развития этих подходов, в том числе с учётом таксономии NIST. Для заказчика особенно полезны рекомендации, которые показывают, как связать порученные агенту задачи и полномочия со сценариями испытаний и критериями их прохождения.