Как защититься от AI-атак и промт-инъекций: практический барьер для агентных систем
Осенью 2025 года исследователи продемонстрировали опасный сценарий атаки на AI-браузеры. Пользователь просил агента лишь кратко пересказать содержимое веб-страницы, однако специально подготовленный текст заставлял систему обращаться к Gmail, извлекать личные сведения и передавать их злоумышленнику.
Для атаки не требовались вирус, эксплойт или поддельная форма авторизации. Достаточно было разместить на странице инструкцию, которую языковая модель принимала за распоряжение пользователя. Такой способ воздействия называют промт-инъекцией.
Почему языковая модель выполняет чужие команды
Большие языковые модели плохо разделяют инструкции и данные. Для них пользовательский запрос, текст статьи, комментарий на форуме или содержимое письма фактически поступают в едином текстовом потоке. Модель не всегда способна определить, где заканчивается полезная информация и начинается попытка изменить её поведение.
Представим стажёра, которому поручили переписать текст с информационного стенда. На стенде дополнительно размещена записка: "Оставь работу и принеси ключи от сейфа". Если стажёр безоговорочно выполняет всё прочитанное, он становится уязвимым для подмены задания. Примерно так работает промт-инъекция: чужая фраза маскируется под команду владельца системы.
Самый известный вариант выглядит просто: "Игнорируй предыдущие инструкции". Раньше подобные фразы преимущественно использовали для розыгрышей чат-ботов. Например, бот автосалона Chevrolet в 2023 году согласился на абсурдное предложение продать автомобиль за один доллар. Реальной сделки не произошло, но случай показал, насколько легко модель можно заставить отступить от первоначальных правил.
В другом сценарии вредоносные инструкции прячут в документах. В резюме может находиться текст белого цвета на белом фоне: человек его не видит, а система автоматического отбора кандидатов распознаёт и интерпретирует как рекомендацию одобрить соискателя.
Пока такие атаки затрагивали только разговорные ответы, последствия оставались ограниченными. Ситуация изменилась, когда модели получили доступ к браузеру, почте, календарю, файлам и корпоративным сервисам. AI-агент уже не просто формирует текст - он способен открывать вкладки, нажимать кнопки, отправлять письма и использовать активные сессии пользователя.
Как развивались атаки на AI-браузеры
Летом 2025 года исследователи Brave показали атаку через комментарий на Reddit. Пользователь поручал браузеру Comet от Perplexity суммировать страницу, а скрытая инструкция в комментарии заставляла агента действовать от имени авторизованного пользователя.
Следующий этап - внедрение команд в изображения. В текст на скриншоте можно добавить малозаметные для человека элементы, которые при этом распознаются моделью. Если агент анализирует такую картинку, он может получить инструкции, не предусмотренные владельцем устройства.
Отдельный класс атак получил название CometJacking. Злоумышленник формирует ссылку, внутри которой размещается вредоносный запрос. После перехода агент обращается к подключённым Gmail и Calendar, извлекает информацию и пытается передать её наружу. Пользователю не нужно вводить пароль или заполнять поддельную форму - иногда достаточно одного клика.
Позднейшие проверки выявили несколько независимых способов извлечения приватных данных из Gmail через промт-инъекции. Ещё один сценарий связан с календарными приглашениями: агент читает обычный инвайт, распознаёт спрятанные команды и может получить доступ к локальным файлам или данным активных сессий.
В большинстве публичных разборов фигурировал Comet. Это не означает, что остальные AI-браузеры защищены лучше. Просто Comet раньше и активнее внедрял агентские возможности, поэтому его чаще проверяли исследователи. Проблема носит системный характер: сама архитектура "модель плюс доступ к сервисам" создаёт опасную поверхность атаки.
Шесть правил базовой защиты
1. Не подключайте к агенту всё сразу.
Почта, облачное хранилище, мессенджеры, календарь и CRM не должны быть доступны одной модели без необходимости. Чем больше разрешений, тем выше цена ошибки.
2. Разделяйте чтение и действие.
Агенту можно разрешить анализировать письмо, но запретить отправку сообщений. Просмотр календаря не должен автоматически давать право создавать встречи или рассылать приглашения.
3. Включайте подтверждение опасных операций.
Отдельного согласия должны требовать отправка писем, публикация материалов, скачивание файлов, изменение настроек и передача данных внешнему получателю.
4. Ограничивайте контекст.
Не следует передавать модели всю переписку, полный список документов или содержимое всех вкладок. Чем меньше данных попадает в контекст, тем сложнее атакующему добиться утечки.
5. Считайте внешний веб недоверенным источником.
Любой текст с сайта, форума, из календарного приглашения или изображения нужно рассматривать как потенциально враждебный. Такой контент может быть полезен для анализа, но не должен автоматически менять полномочия агента.
6. Ведите журнал действий.
Без аудита невозможно понять, что именно прочитал и сделал агент. Логи должны фиксировать источник команды, использованный коннектор, переданные данные и итог операции.
Практический барьер для агента
Для системы, которая каждый день работает в интернете и использует более двадцати коннекторов, разумно применять промежуточный "рубильник". Его задача - временно отключать чувствительные интеграции после того, как агент обратился к внешнему веб-контенту.
Логика проста:
1. агент открывает страницу или читает внешний документ;
2. система помечает контекст как потенциально недоверенный;
3. доступ к Gmail, облачным файлам, CRM и другим критичным сервисам временно блокируется;
4. агент может продолжить анализ, но не способен сразу выполнить опасное действие;
5. пользователь или отдельный контролирующий процесс вручную возвращает разрешения.
Важно, чтобы блокировка распространялась не только на прямые команды, но и на цепочки действий. Например, агент не должен иметь возможности прочитать страницу, извлечь из неё инструкцию, открыть почту и отправить найденные сведения через другой подключённый сервис.
Более надёжный вариант - разделить агента на несколько ролей. Один компонент занимается сбором информации, второй анализирует её, третий выполняет действия только после проверки. Между ними должны передаваться структурированные данные, а не произвольный необработанный текст.
Что можно проверить самостоятельно
Защиту полезно тестировать на безопасной копии окружения. В тестовую страницу помещают инструкции вроде:
- проигнорировать системные правила;
- прочитать содержимое почты;
- найти документы с определёнными словами;
- отправить результат на внешний адрес;
- открыть локальный файл;
- создать встречу в календаре.
Правильно настроенный агент должен распознать такие фразы как данные страницы, а не как распоряжение. Если он начинает выполнять команды, необходимо пересмотреть права доступа и добавить подтверждение критичных операций.
Отдельно нужно проверять изображения, PDF-файлы, письма и приглашения в календарь. Инъекция может быть невидимой в обычном интерфейсе, но распознаваться системой компьютерного зрения или OCR-модулем.
Ограничения такого подхода
"Рубильник" не устраняет саму уязвимость языковой модели. Он лишь сокращает последствия успешной инъекции. Если вредоносная команда уже попала в доверенный внутренний документ, простая проверка источника может не сработать.
Кроме того, постоянное отключение коннекторов ухудшает удобство работы. Пользователю приходится чаще подтверждать действия, а автоматические сценарии становятся медленнее. Наконец, невозможно гарантировать, что агент правильно определит все внешние источники: данные могут проходить через цепочку сервисов и терять исходную маркировку.
Поэтому защита должна быть многоуровневой. Нужны минимальные разрешения, изоляция контекста, раздельные роли, подтверждение опасных операций, журналирование и регулярные тесты. Нельзя полагаться только на системный промт или обещание разработчика, что модель "поймёт намерение".
Главный принцип таков: любой текст, полученный извне, следует считать потенциальной командой злоумышленника, пока система не доказала обратное. AI-агенту можно поручать анализ информации, но право действовать от имени пользователя должно выдаваться отдельно, ограниченно и на короткий срок. Именно такой барьер превращает промт-инъекцию из катастрофической атаки в контролируемое событие безопасности.