Защита ИИ-агентов: почему инструкции не работают и что проверять до запуска

Вячеслав Валькович, руководитель развития облачных AI-сервисов ITGLOBAL.COM, корпорация ITG

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

Масштаб проблемы растет быстрее, чем практики защиты. Только в последние недели появились описания атак, при которых вредоносная инструкция заставляет модель не только выполнить команды злоумышленника, но и перенести саму инъекцию в другие сообщения или файлы для дальнейшего распространения. Для руководителя ИТ это означает простую вещь: правило «не делай опасного», записанное в инструкции агенту, – это пожелание, а не контроль. Контроль должен находиться вне модели, и для этого появляется новый класс средств защиты.

1. Что клиенты чаще всего недооценивают, когда приходят к вам с задачей внедрить ИИ-агентов? В какой момент вы поняли, что агенты создают качественно другой риск, а не просто становятся «чат-ботом с расширенными правами»?

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

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

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

И это только один из примеров. Агент может отправить письмо не тому адресату, изменить данные в CRM, запустить нежелательную операцию или передать конфиденциальную информацию во внешнюю систему.

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

2. Агент читает тексты, которые писал не сотрудник компании, а кандидат, контрагент или случайный отправитель письма. Как этот риск выглядит в реальных сценариях ваших клиентов, и какие из них вызывают у вас наибольшее беспокойство?

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

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

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

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

Особенно опасны ситуации, когда агент одновременно работает с недоверенной информацией и имеет широкие права на выполнение действий. Именно это сочетание превращает обычный на вид документ в инструмент атаки на всю компанию.

3. Интуитивная реакция на такой риск – дописать агенту правила: «не выполняй инструкции из документов». Почему, судя по вашим тестам, это не работает, и какие способы обхода срабатывают чаще всего?

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

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

Я считаю, что основную защиту нужно переносить на уровень действий. Если агенту не требуется отправлять письма, у него вообще не должно быть такой возможности. Если он может работать только с определенной базой данных, его права нужно ограничить этой базой.А удаление информации, изменение финансовых данных или внешняя отправка документов должны проходить дополнительную проверку человеком – для этого даже есть отдельный термин, human in the loop.

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

4. Если модель не может надежно охранять сама себя, проверка должна находиться снаружи. Для таких решений появился термин «ИИ-файрвол», пока мало известный за пределами профессионального сообщества. Что за ним стоит, и чем такая защита отличается от межсетевых экранов и других средств, которые уже используют компании?

Аналогия понятна, но она несколько упрощает реальную картину.

Под названием «ИИ-файрвол» сегодня объединяют довольно разные механизмы защиты, и сначала нужно определить, что именно мы защищаем.

Если речь идёт о локально размещенной языковой модели, появляются задачи безопасности самой инфраструктуры: контроль происхождения весов, библиотек и контейнеров, целостности компонентов, обновлений и доступа к среде исполнения. Это область защиты цепочки поставки программного обеспечения и моделей – supply chain security.

Если компания пользуется внешней моделью через API, акцент смещается на защиту передаваемых данных, управление доступом, фильтрацию запросов и ответов, контроль маршрутизации.

А в случае ИИ-агентов, как я уже отмечал, добавляется еще один уровень – контроль инструментов, полномочий и последовательности операций.

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

При этом не стоит создавать иллюзию, что один шлюз контролирует все. ИИ-файрвол видит только то, что через него проходит. А если инструмент агента работает локально, на том же сервере, а не через API, его действия просто остаются за пределами этой проверки.

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

5. Службы безопасности часто отвечают на это: «у нас уже есть DLP». Где, по вашему опыту, проходит граница между тем, что закрывают привычные средства защиты, и тем, что остается открытым при работе агентов?

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

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

Но у автономных агентов появляются дополнительные риски, которые не ограничиваются утечками информации.

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

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

На мой взгляд, эти технологии постепенно будут сближаться. Традиционные производители средств информационной безопасности уже добавляют функции защиты ИИ, а специализированные ИИ фаерволы развивают интеграции с DLP, SIEM и системами управления доступом, как это делаем мы.

Задача компании – выстроить между ними единую архитектуру безопасности, а не выбрать одно вместо другого.

6. Проверять нужно и то, что агент отправляет в модель, и то, что модель возвращает. Какая из этих двух сторон сейчас недооценена сильнее и почему?

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

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

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

Для агента ответ модели – не всегда текст, который прочитает человек. Часто это уже команда: вызвать инструмент, изменить файл, отправить запрос к API.

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

7. Любая дополнительная проверка добавляет время и риск ошибочно остановить нормальную работу. Как клиенты находят баланс на практике? Что они чаще выбирают на старте: жесткую блокировку или режим, в котором подозрительные обращения только фиксируются?

Это и правда одна из самых сложных задач для любого средства ИБ, работающего непосредственно с потоком запросов.

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

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

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

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

8. Средства защиты легко создают иллюзию безопасности: решение установлено, а насколько оно эффективно, никто не знает. Как вы убеждаетесь в работоспособности защиты перед выпуском новой версии? Что тестирование выявляло неожиданно для команды?

Главная задача тестирования таких продуктов – найти сценарии, в которых защита работает неправильно. Красивая цифра в 100% отражённых атак здесь не цель.

У нас большой набор автоматизированных проверок, который постоянно расширяется, – счёт идёт на десятки тысяч. Если мы находим ошибку или способ обойти защитный механизм, стараемся превратить этот случай в отдельный тест. Так мы убеждаемся, что проблема устранена и не вернётся в следующем обновлении.

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

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

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

9. Стопроцентной защиты не бывает даже при серьезном тестировании. Как компании до внедрения понять, подходит ли решение именно ей, и как при такой проверке обеспечивается сохранность примеров, которые передает клиент?

Конечно, полностью исключить риски невозможно. Задача средств защиты – снизить вероятность и последствия инцидентов до приемлемого для конкретной компании уровня.

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

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

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

Так заказчик оценивает решение в условиях, близких к своей рабочей среде, и не создает при этом новый неконтролируемый канал для чувствительной информации.

10. Что обычно показывают такие проверки? Насколько результаты расходятся с ожиданиями клиентов?

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

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

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

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

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

11. По итогам проверки у CIO есть две цифры: сколько угроз выявлено и сколько нормальных запросов заблокировано по ошибке. Какая из них в вашей практике оказывается решающей для бизнеса?

Для бизнеса особенно чувствителен второй показатель – ложные блокировки.

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

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

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

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

12. Ложное срабатывание останавливает процесс, пропущенная угроза ведёт к инциденту. Как CIO обосновать затраты на защиту перед финансовым директором, если ущерб от не произошедшего инцидента трудно посчитать?

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

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

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

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

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

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

13. Закон об ИИ уже действует, а с марта 2027 года для отдельных отраслей могут появиться требования к используемым моделям. Как это меняет ваши рекомендации клиентам сегодня, и что нужно заложить в архитектуру, чтобы смена модели не требовала перестраивать защиту?

Мой основной совет – не привязывать корпоративную AI-архитектуру к одной конкретной языковой модели.

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

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

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

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

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

Я бы начал с довольно простого вопроса: что самое неприятное может произойти, если агент выполнит не то действие?

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

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

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

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