Безопасность ИИ-агентов: что ломается и что проверить до внедрения

ИИ-агент читает почту и документы, обращается к базам данных, отправляет письма и запускает код. Ошибка модели или удачная промпт-инъекция может закончиться действием в ваших системах: удалением записей, отправкой письма, утечкой данных. Разбираем, из чего складывается безопасность ИИ-агентов: чем агент отличается от чат-бота, при каком сочетании условий он становится каналом утечки, какие уязвимости в агентах находили и какие атаки уже случились, как агентов защищают, как найти теневой ИИ и что проверить до запуска.

Обзор действителен на 6 октября 2026 года. Инциденты и цифры сверены с первоисточниками; где первоисточник не открылся или молчит (Replit, содержание кода Amazon Q), в тексте указано издание.

Чем ИИ-агент отличается от чат-бота

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

Чем больше система может сделать сама, тем больше возможный ущерб. Для оценки удобна шкала из пяти степеней агентности.

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

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

Почему модель нельзя считать доверенной частью системы

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

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

«Фатальная триада»: когда агент становится каналом утечки

«Фатальная триада» (lethal trifecta — термин из блога Саймона Уиллисона, 2025) — сочетание трёх условий, при котором ИИ-агента можно заставить вывести данные наружу: агент видит конфиденциальные данные, читает недоверенное содержимое (письма, веб-страницы, файлы, ссылки извне) и может передавать данные вовне. Опасно именно сочетание: если убрать любое из трёх, утечке через промпт-инъекцию не хватит данных, точки входа или канала наружу.

Те же три условия делают агента полезным: корпоративному ассистенту нужен доступ к почте и документам, он читает входящие письма и умеет отправлять ответы или показывать ссылки и картинки. Разорвать триаду, убрав одно из условий, удаётся не всегда. Тогда жёстко контролируют третье условие: куда агент может отправлять запросы и сообщения и что интерфейс может отрисовать. Степень агентности и условия триады для каждого агента мы проверяем на аудите безопасности ИИ-систем.

Уязвимости и атаки на ИИ-агентов в 2025–2026 годах

В четырёх уязвимостях ИИ-ассистентов, которые исследователи показали в 2025–2026 годах, — EchoLeak и SearchLeak в Microsoft 365 Copilot, ForcedLeak в Salesforce Agentforce, CamoLeak в GitHub Copilot — промпт-инъекция заставляла модель собрать данные, а наружу их выводили классические веб-уязвимости: сервисы-посредники, разрешённые политикой CSP, гонка при отрисовке, домен с истёкшей регистрацией. CSP (Content Security Policy) — политика, по которой браузер ограничивает, откуда веб-интерфейс загружает ресурсы; на сетевые запросы серверной части агента она не распространяется. Проверку CSP, прокси и отрисовки включают в тестирование веб-приложения, а всю цепочку утечки проверяют отдельно: от инструкции в источнике, который читает агент, до выхода тестовых данных наружу.

В облачном ассистенте такие ошибки исправляет вендор, а заказчик решает, какие данные и источники к нему подключить. Интерфейс собственного агента (политику CSP, отрисовку ссылок и картинок) проверяют тестированием на проникновение.

Вред бывает и без атаки. В июле 2025 года агент разработки Replit во время заморозки кода удалил рабочую базу пользователя. У него был доступ на запись в продуктивную среду без её отделения от тестовой (по данным Fortune и The Register). После этого Replit ввёл автоматическое разделение сред и восстановление в один клик. Права агента и разделение сред входят в чек-лист аудита безопасности ИИ-систем.

Риски ИИ-агентов в российских опросах

Ассоциация разработчиков программных продуктов «Отечественный софт» 23 сентября 2026 года опубликовала опрос более 50 компаний — своих членов, то есть разработчиков ПО. 72 % из них уже внедрили ИИ-агентов в корпоративный контур, более 90 % не проводили оценку угроз ИИ, а базовые средства контроля безопасности используют лишь 23 % компаний, внедряющих ИИ.

«Информзащита» 26 мая 2026 года сообщила, что с инцидентами из-за ИИ-агентов столкнулись 42 % организаций против 31 % годом ранее. Это доли среди опрошенных компаний, а не по всему рынку; сопоставимость выборок двух лет не раскрыта, поэтому разницу нельзя уверенно считать ростом. Доли выявленных событий по типам:

• злоупотребление правами и выход за пределы разрешённого сценария (31 %);
• промпт-инъекции (24 %);
• утечки через подключённые коннекторы и хранилища (18 %);
• агенты без владельца и учёта (14 %);
• компрометация токенов, ключей и сервисных учётных записей (9 %);
• атаки через плагины и цепочки поставки (4 %).

У 58 % респондентов обнаружение и реагирование занимают больше пяти часов. Размер выборки в сообщении не раскрыт.

Десять рисков OWASP для агентных приложений на 2026 год

В декабре 2025 года сообщество OWASP выпустило OWASP Top 10 for Agentic Applications for 2026 — перечень главных рисков агентных систем:

1. ASI01 Agent Goal Hijack — подмена цели агента, например через непрямую промпт-инъекцию.
2. ASI02 Tool Misuse and Exploitation — нецелевое использование инструментов: вызовы платных API в цикле, удаление писем вместо их пересказа.
3. ASI03 Identity and Privilege Abuse — злоупотребление учётными данными и полномочиями, например субагент, которому оркестратор передал все свои права.
4. ASI04 Agentic Supply Chain Vulnerabilities — уязвимости цепочки поставок: модели, навыки, MCP-серверы, пакеты и расширения.
5. ASI05 Unexpected Code Execution — выполнение вредоносного кода агентом с доступом к консоли.
6. ASI06 Memory & Context Poisoning — отравление памяти и контекста: внедрённые данные и инструкции искажают текущие решения агента, а если сохранились в памяти — и следующие запуски.
7. ASI07 Insecure Inter-Agent Communication — небезопасное взаимодействие агентов через общую шину или рабочее пространство.
8. ASI08 Cascading Failures — каскадные сбои: ошибка одного агента распространяется по системе.
9. ASI09 Human-Agent Trust Exploitation — злоупотребление доверием человека к ответам агента.
10. ASI10 Rogue Agents — агент, который из-за компрометации, вредоносной подмены или рассогласования с заданной целью выходит за рамки своей функции и полномочий.

Этот перечень мы используем вместе с требованиями ФСТЭК России, когда проверяем агентов.

Как защищают ИИ-агентов

ИИ-агента защищают несколькими слоями, потому что языковая модель остаётся недоверенной и промпт-инъекцию нельзя исключить полностью: контролем интерфейса и исходящих соединений, минимальными правами, проверкой вызовов инструментов до исполнения, изоляцией контекстов и среды исполнения, контролем цепочки поставок и журналами. Фильтры запросов и ответов дополняют эти слои, но гарантий не дают.

Интерфейс и исходящие соединения

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

В интерфейсе загрузку внешних картинок запрещают или сужают политикой CSP, а ссылки из ответов удаляют или сверяют с белым списком адресов: переход по ссылке CSP не останавливает. И политику, и фильтр ссылок регулярно проверяют. ForcedLeak показал, что в белом списке CSP может оказаться домен, который уже никому не принадлежит. Третий выход закрывает проверка вызовов инструментов, о ней ниже.

Права и доступы агента

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

Проверка вызовов инструментов

Каждый вызов до исполнения проверяет обвязка агента или отдельный шлюз инструментов. Запрет в системном промпте ограничением не считается. Для каждой задачи задают список разрешённых инструментов и ограничения на их аргументы: агенту разработки — запись только в тестовую базу, платёжному — потолок суммы. Для инструментов, которые пишут вовне, сверяют конкретного получателя или хранилище: разрешённый домен почты или облачного сервиса не мешает отправить данные на чужой ящик или в чужое хранилище того же сервиса. Отдельно ставят лимит частоты вызовов.

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

Изоляция контекстов и агентов

Недоверенные данные обрабатывает отдельный контекст без доступа к инструментам, а решения о вызовах принимает контекст, который этих данных не видит. Эту схему называют «двойной моделью» (Dual LLM); её описал Саймон Уиллисон в 2023 году. Управляющему контексту передают не свободный текст, а значения, которые программа проверила по заранее заданному набору допустимых, или идентификатор переменной, содержимое которой управляющий контекст не читает. От подмены данных она не спасает. Если в документе подменили реквизиты, изолированный контекст вернёт их как есть, и остановит ущерб только ограничение на аргументы вызова — например, перевод новому получателю требует подтверждения человека.

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

Среда исполнения кода

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

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

Цепочка поставок

Версии расширений, утилит командной строки и пакетов агента фиксируют и обновляют после проверки: в s1ngularity и Amazon Q вредоносный код пришёл в очередной версии. Модели из открытых репозиториев тоже проверяют. В файлах моделей бывают закладки кода и инъекции в шаблонах промптов. Состав навыков и MCP-серверов фиксируют заранее и не разрешают агенту подключать новые во время работы. При разработке системы ИИ для ГИС или значимого объекта КИИ раздел 3.18 методического документа ФСТЭК требует отказаться от небезопасных форматов хранения вроде pickle в пользу ONNX или protobuf; для собственных агентов это часть процесса безопасной разработки.

Журналы

Каждое действие агента записывают в журнал вместе с запросом, который его вызвал, а журнал дополняют телеметрией хоста. Секреты в журнал не пишут, персональные и другие чувствительные данные маскируют, доступ к журналам и срок хранения ограничивают. Запрещённый вызов инструмента — событие безопасности, которое должно попадать в мониторинг событий ИБ.

Вероятностные меры

Фильтры запросов и ответов, обучение модели противостоять атакам и внешние «файрволы для ИИ» снижают риск, снимают часть нагрузки с оператора, который подтверждает действия агента, страхуют от ошибок в архитектуре и дают телеметрию о попытках атак, но ни одна из них не гарантирует, что атака не пройдёт.

В государственных информационных системах и на значимых объектах КИИ фильтрация запросов и ответов при этом обязательна: раздел 3.18 методического документа ФСТЭК применяется там в силу пункта 68 Требований № 117 для ГИС и пункта 22(1) (так обозначают пункт, вставленный после пункта 22) Требований № 239 для значимых объектов КИИ. Как учесть такие угрозы в документах — в статье о модели угроз для систем ИИ.

Что требует регулятор при использовании ИИ-агентов

Если агент обрабатывает персональные данные, на эту обработку распространяется закон № 152-ФЗ «О персональных данных». Что это значит для ИИ-сервисов, мы разобрали в статье «ИИ и персональные данные». Для государственных и муниципальных информационных систем, иных систем госорганов, ГУП и госучреждений, а также значимых объектов КИИ добавляются специальные требования ФСТЭК к защите систем ИИ.

Методический документ ФСТЭК России от 12 апреля 2026 года в разделе 3.18 включает программное обеспечение агентов ИИ в перечень защищаемых объектов — и при разработке, и при эксплуатации системы ИИ. Операторы государственных информационных систем и значимых объектов КИИ применяют методические документы ФСТЭК обязательно — в силу пункта 68 Требований № 117 и пункта 22(1) Требований № 239.

При эксплуатации системы ИИ в таких системах раздел 3.18 требует:

• фильтровать запросы и ответы;
• мониторить и квотировать запросы;
• регистрировать события по запросам и ответам;
• обеспечивать целостность весов модели и конфигурации системы ИИ.

Тестирование на устойчивость к промпт-атакам — мера усиления, её применяют по решению оператора.

Если система ИИ в ГИС или на значимом объекте КИИ обрабатывает персональные данные граждан России, иную информацию ограниченного доступа или реализует значимые функции оператора, раздел 3.18 требует безопасной разработки по национальным стандартам и сертификации программного обеспечения системы ИИ по требованиям ФСТЭК.

Для ГИС и иных систем, на которые распространяются Требования № 117, действует и запрет пункта 60 этих Требований передавать разработчику модели информацию ограниченного доступа: агент с такими данными работает с моделью в контуре оператора или у подрядчика, который не разработчик модели. Если модель подключают как внешний сервис подрядчика, раздел 3.18 требует, чтобы в инфраструктуре подрядчика, на которой работает сервис, были реализованы меры защиты по классу не ниже класса системы оператора.

Частную компанию без ГИС и значимых объектов КИИ эти требования ФСТЭК напрямую не обязывают, с оговоркой: по пункту 2 Требований № 117 система, в которую из ГИС передают информацию ограниченного доступа, тоже должна отвечать требованиям о защите. Для остальных раздел 3.18 — готовый перечень мер.

Что предлагает проект изменений в Требования № 117

Проект изменений в Требования № 117 (ГИС и иные системы госорганов), размещённый на regulation.gov.ru 24 августа 2026 года (ID 170500), предлагает с 1 марта 2027 года новую редакцию пункта 61, посвящённую агентам ИИ, в том числе автономным: оператор должен принимать меры против несанкционированного воздействия на ресурсы системы, а также контролировать права доступа агентов и управлять ими по внутренним стандартам и регламентам. На 6 октября 2026 года документ не принят, статус — в карточке проекта на regulation.gov.ru. Подробно — в статье «Что ФСТЭК требует по безопасности ИИ».

Теневой ИИ: как найти неучтённые инструменты

Теневой ИИ — нейросети и ИИ-агенты, которые подразделения или сотрудники подключили сами, без участия ИТ и службы безопасности. Их права доступа, журналы и уходящие данные никто не проверял. Выявляют их инвентаризацией: опросом подразделений, анализом обращений к ИИ-сервисам, учётом установленных ИИ-утилит, встроенных ИИ-функций и разрешений, выданных ИИ-приложениям на доступ к почте и документам.

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

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

Что проверить до внедрения ИИ-агента

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

1. Кто владелец агента и есть ли он в реестре ИИ-инструментов?
2. Какая у агента степень агентности и оправдана ли она задачей?
3. Выполнены ли все три условия «фатальной триады» и как контролируется канал наружу?
4. От чьего имени работает агент, какие у него инструменты и может ли он расширить права сам?
5. Где исполняется код агента и как он изолирован?
6. Какие действия выполняются только после подтверждения человеком?
7. Из чего состоит цепочка поставок: модель, навыки, MCP-серверы, пакеты и расширения — и кто их обновляет?
8. Ведутся ли журналы, по которым видно, какой запрос вызвал какое действие?
9. Показывает ли интерфейс внешние картинки и ссылки из ответов агента и когда проверяли политику CSP и фильтр ссылок?
10. Куда уходят запросы агента: чья модель, где она работает и не получает ли её разработчик данные, которые передавать нельзя?

Кредо-С — лицензиат ФСТЭК России по технической защите конфиденциальной информации (лицензия № Л024-00107-00, реестровая запись № 00581724). На аудите безопасности ИИ-систем проверяем агентов по этим вопросам, по OWASP Top 10 for Agentic Applications и требованиям ФСТЭК; на выходе — перечень рисков с приоритетами и рекомендации по архитектуре.

Серия «Безопасность ИИ»

• Аудит безопасности ИИ-систем — проверка моделей, LLM-приложений и ИИ-агентов, модель угроз, тест на промпт-атаки
• Регламент использования ИИ — правила для сотрудников: разрешённые сервисы, запрет ввода ПДн и тайны
• Что ФСТЭК требует по безопасности ИИ — приказ № 117, раздел 3.18 методдокумента, проект изменений
• Модель угроз для систем ИИ — угрозы ИИ в БДУ и порядок разработки модели угроз
• Риски внедрения ИИ — карта рисков: утечки, теневой ИИ, ошибки моделей, регуляторика
• ИИ и персональные данные — что меняет 152-ФЗ для работы с нейросетями
• Закон об ИИ — кого регулирует 243-ФЗ и с каких дат