Как хакеры вынуждают ИИ-агентов работать на себя. И что с этим делать

Промпт-инъекции — ключевая угроза

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

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

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

Состязательные атаки

Состязательные атаки — преднамеренные манипуляции с входными данными, которые заставляют ИИ-модель ошибаться. Если промпт-инъекции актуальны для генеративного ИИ и LLM, то состязательные атаки применяются там, где работает машинное обучение. Наиболее часто в компьютерном зрении (беспилотные автомобили, системы распознавания лиц), а также в классификаторах звука или спам-фильтрах.

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

Разберем примеры состязательных атак.

Атаки на данные

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

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

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

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

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

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

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

Вот пять практических шагов для защищенного внедрения ИИ-агентов.

1. Ограничьте полномочия по принципу минимальных привилегий.

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

2. Разделяйте чтение, рассуждение и действие.

Работа агента должна быть постадийной. Прочитать документ — одно действие. Сформировать вывод — другое. Изменить данные или отправить письмо — третье. Для критичных операций обязательно требуется подтверждение пользователя или ИИ-модель «внутренний аудитор», которая следит за основным агентом и не дает ему выполнить опасное действие, даже если основной агент был обманут.

3. Разделяйте доверенные и недоверенные источники.

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

4. Контролируйте критические операции.

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

5. Логируйте и проверяйте поведение.

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