NIST 9 ноября опубликовал первый публичный проект SP 2400-102 E2026 с отдельной главой об атаках на агентные системы. Документ раскладывает безопасность ИИ-агентов на вполне прикладные сценарии: злоумышленник может подсунуть инструкцию в письмо, базу знаний, описание инструмента или долговременную память агента — и попытаться заставить его действовать против интересов пользователя. Для российских команд, внедряющих агентов в поддержку, разработку и бэк-офис, это готовый словарь для модели угроз и плана проверок.
Проект развивает таксономию атак на системы машинного обучения, подготовленную NIST в 2025 году, и охватывает предиктивные, генеративные и агентные системы. Как пишет Habr / Новости, замечания к новой версии принимают до 18 декабря 2026 года. Итоговый стандарт появится позже, но сам проект уже полезен: он помогает не спорить о том, является ли найденный кейс «просто странным поведением LLM», а описать точку входа, возможности атакующего, последствия и защитные барьеры.
Главная особенность агентов — они не только отвечают текстом. Они строят планы, вызывают API, читают документы, сохраняют сведения между сессиями и иногда координируются с другими агентами. Поэтому ошибка в интерпретации входных данных способна закончиться не неудачной формулировкой ответа, а попыткой отправить письмо, удалить запись, выгрузить данные или запустить дорогую цепочку операций. NIST предлагает рассматривать атаку по этапам жизненного цикла: постановка задачи, планирование, выполнение действий, получение ответа от инструмента и корректировка плана.
Цели атак при этом вполне привычны специалистам по ИБ: отказ в обслуживании, нарушение целостности, раскрытие чувствительных данных и использование системы для вредоносных действий. Например, агенту можно навязать бесконечные вызовы инструментов, чтобы он сжигал вычислительные ресурсы и не завершал задачу. В другом сценарии он меняет ход работы или выполняет действие, которое пользователь не заказывал. Разница лишь в том, что граница между данными и инструкцией у LLM часто оказывается менее надёжной, чем хотелось бы архитекторам интеграции.
Где атакующий может вмешаться
Самый известный путь — прямой запрос пользователя: обход ограничений и разбиение опасной цели на безобидные с виду шаги. Но для агентных систем не менее важна косвенная промпт-инъекция. Вредоносная инструкция попадает в веб-страницу, вложение, документ или базу знаний; агент читает источник во время работы и принимает чужой текст за указание к действию. Если такой фрагмент сохраняется в долговременной памяти, воздействие переживает один диалог и превращается в закрепление: последующие задачи агент выполняет уже с отравленным контекстом.
Отдельно NIST выделяет цепочку поставки. Атакующий может повлиять на модель до подключения к агенту, на обучающие данные, компоненты дообучения или сам процесс интеграции. Не стоит сводить риск только к базовой модели: в агентном продукте уязвимой поверхностью становятся коннекторы, навыки, системные инструкции и описания доступных функций. Если в описание инструмента встроена вредоносная подсказка, агент может поменять план ещё до вызова API. Если опасный код находится внутри инструмента, последствия уже ближе к классическому компрометированному dependency: утечка данных, несанкционированные действия или блокировка процесса.
Мультиагентные схемы добавляют ещё один канал. Компрометация одного участника позволяет передавать подложные сообщения другим агентам, которые могут счесть их легитимными рабочими указаниями. Чем больше автономии, интеграций и общего состояния у такой системы, тем важнее явно обозначать доверенные границы. Сообщение от «соседнего» агента, результат поиска и текст из CRM не должны автоматически получать тот же уровень доверия, что и подтверждённая команда пользователя.
Проверять нужно не только модель
NIST рассматривает защиту на двух уровнях. Модель можно обучать отличать поручение пользователя от инструкций в недоверенном контенте, однако эта защита не гарантирует устойчивость против специально подобранных атак. Системный слой должен ограничивать передачу данных и выполнение операций даже тогда, когда модель уже пошла по ложному следу. Сюда относятся минимальные права для инструментов, изолированное выполнение потенциально опасного кода, лимиты вызовов и независимая проверка допустимости операции.
Практический тест легко представить на агенте службы поддержки. Он готовит ответ клиенту и имеет доступ к почтовому сервису, но отправка должна проходить подтверждение сотрудника. Вложенный документ содержит скрытое для пользователя требование немедленно отправить письмо. Испытатели запускают одинаковую задачу с такой инструкцией и без неё, затем сопоставляют логи агента с журналом почтового сервиса. Если агент попытался обойти согласование, проблема уже зафиксирована. Если сервис отклонил вызов без подтверждения, системный контроль отработал, хотя модель и подверглась влиянию.
Если письмо всё же ушло, отчёт должен содержать условия обхода, последовательность действий и границы проверки — иначе команда не сможет воспроизвести дефект после исправления. Такой подход перекликается с категорией Excessive Agency в руководствах OWASP: опасные действия нельзя оставлять на усмотрение модели без независимого контроля и, где нужно, человека в контуре. Для российских проектов основу процесса безопасной разработки может задавать ГОСТ Р 56939-2024, а таксономия NIST — помогать выбирать и точно формулировать актуальные сценарии угроз.
Проект NIST не обещает универсальный фильтр от инъекций и не отменяет обычную инженерную дисциплину. Он подсказывает более полезный вопрос для владельца продукта: какие данные агент читает, что он может сделать после чтения и какой независимый барьер остановит ошибочное действие. По мере того как агенты получают доступ к корпоративным системам, безопасность ИИ-агентов всё меньше будет задачей настройки промпта и всё больше — задачей проектирования прав, журналирования, изоляции и проверяемых сценариев отказа.
