Внедрение подсказок стало одной из самых неприятных проблем безопасности в системах искусственного интеллекта. Злоумышленник подсовывает модели текст, который выглядит как обычные данные, но внутри работает как команда.
Модель должна была прочитать письмо, страницу или документ, а вместо спокойного анализа получает чужую инструкцию: изменить ответ, скрыть часть сведений, перейти по ссылке, отправить данные или выполнить действие через подключенный инструмент.
Опасность выросла вместе с ИИ-агентами. Обычный чат-бот может выдать странный ответ, а агент уже работает с почтой, сайтами, файлами, календарем, платежами и внутренними базами.
Когда вредная инструкция попадает в такой контур, атака перестает быть игрой с текстом и превращается в попытку управлять посредником, у которого есть права пользователя.
Главная проблема: для языковой модели внешняя страница, письмо и документ остаются текстом. Если внутри текста спрятана команда, модель должна сама понять, где данные, а где приказ. Такая граница часто оказывается слишком мягкой.
Свежие публикации Google и Forcepoint показывают, что тема вышла из лабораторий. Google проверяла открытый веб через Common Crawl и нашла разные классы непрямого внедрения подсказок: от безобидных шуток и попыток управлять пересказами до поисковой накрутки, кражи данных и команд на разрушительные действия. Forcepoint отдельно разобрала десять живых нагрузок на публичных сайтах, где инструкции прятались в комментариях HTML, невидимых блоках, служебных метаданных и разметке для доступности.
Прямое и непрямое внедрение подсказок
Прямое внедрение происходит в лоб. Пользователь сам пишет модели вредную инструкцию и пытается заставить систему забыть правила, раскрыть внутреннюю подсказку, обойти запрет или выполнить чужую роль. Такой сценарий старый и хорошо знакомый: человек спорит с чат-ботом, подбирает формулировки, давит на модель длинными указаниями, просит «игнорировать прежние инструкции» и проверяет, где защита треснет.
Непрямое внедрение устроено неприятнее. Пользователь может вообще не быть злоумышленником. Вредную инструкцию заранее оставляет автор страницы, отправитель письма, владелец документа, участник обсуждения, кандидат в резюме или любой человек, чей текст потом попадет в окно модели. Пользователь просит ИИ «кратко пересказать письмо» или «проверить сайт», а модель вместе с обычным содержанием читает скрытую команду атакующего.
Команду вводит сам пользователь в чате. Цель чаще сводится к обходу правил или раскрытию служебных сведений.
Команда спрятана в письме, сайте, документе, комментарии или метаданных, которые читает модель.
Вредная инструкция пытается вызвать инструмент: почту, календарь, браузер, файлы, платежи или внутренний сервис.
| Сценарий | Кто вводит вредную инструкцию | Где прячется команда | Типичный риск |
|---|---|---|---|
| Прямое внедрение | Пользователь в чате | В самом запросе | Обход правил, раскрытие служебных сведений, вредный ответ |
| Непрямое внедрение | Третья сторона | В письме, сайте, документе, комментарии, метаданных | Утечка данных, подмена сводки, лишнее действие агента |
| Внедрение через агента | Третья сторона или скомпрометированный источник | В любом содержимом, которое агент читает перед действием | Письма, платежи, изменение файлов, переходы, вызов инструментов |
Главная разница между обычной атакой на сайт и внедрением подсказок в ИИ лежит в границе между данными и командой. В базе данных разработчик может отделить запрос от пользовательского текста. В языковой модели все приходит как язык. Система видит инструкции разработчика, вопрос пользователя, текст страницы и вложенный мусор в одном смысловом поле. Когда модель достаточно послушна и достаточно самостоятельна, чужая фраза превращается в рычаг управления.
Почему старые привычки безопасности здесь плохо работают
Британский Национальный центр кибербезопасности в разборе NCSC отдельно предупредил, что внедрение подсказок опасно сравнивать с SQL-инъекциями слишком буквально. SQL-инъекции удалось сильно обуздать, потому что команды и данные можно разделить технически. У больших языковых моделей такой жесткой внутренней перегородки нет: текст письма, просьба пользователя и скрытая команда попадают в одну языковую смесь.
Отсюда неприятный вывод. Нельзя просто написать одну «идеальную проверку» и закрыть класс атак навсегда. Фильтр по словам тоже быстро ломается: исследовательские статьи, учебные материалы и новости по безопасности используют те же формулировки, что вредные нагрузки. Google в апрельском исследовании прямо пишет, что грубый поиск по фразам дает множество ложных срабатываний, поэтому компании пришлось сочетать поиск по признакам, оценку модели и ручную проверку.
Проблема усиливается из-за роста полномочий ИИ. Чат-бот без доступа к инструментам может испортить ответ. Агент с доступом к почте, календарю, внутренним документам и браузеру может сделать то, что раньше делал сотрудник.
Вредная инструкция уже не просто «убеждает текст», а пытается подтолкнуть посредника с правами пользователя к действию. Такой посредник может выглядеть как удобный помощник, но с точки зрения атакующего агент превращается в новую точку входа.
Как выглядит цепочка атаки
Базовая цепочка обычно короткая. Злоумышленник размещает инструкцию там, где человек ее не заметит или не воспримет как команду. Веб-страница может содержать невидимый блок через CSS, HTML-комментарий, мелкий белый текст, служебный тег, подпись к изображению или строку в метаданных. Письмо может выглядеть как обычная переписка, но содержать скрытый текст, который читает сводчик писем.
Потом ИИ-агент получает задачу от пользователя. Например, «найди лучшие предложения», «перескажи непрочитанные письма», «проверь страницу поставщика», «изучи документацию», «составь ответ по вложениям». Агент забирает внешнее содержимое, отправляет текст в модель, а модель сталкивается с инструкцией, которая обращается уже не к человеку, а к самому агенту.
Последний шаг зависит от прав агента. Если агент только пересказывает, атака подменит тон, выводы, рекламу, рейтинг товара или предупреждение. Если агент умеет ходить по ссылкам, атака поведет его на нужную страницу. Если агент умеет отправлять письма, работать с терминалом, календарем, платежами или корпоративными файлами, последствия быстро становятся похожи не на «странный ответ нейросети», а на обычный инцидент безопасности.
- Сайт подсовывает агенту невидимую инструкцию и просит рекламировать конкретный сервис.
- Письмо заставляет сводчик показать фальшивое предупреждение о взломе аккаунта.
- Документ просит модель раскрыть данные из соседних файлов или переписки.
- Календарная встреча пытается включить другой инструмент и выполнить действие от имени пользователя.
- Описание задачи в системе разработки подталкивает помощника к запуску опасной команды.
Что нашли Google и Forcepoint в открытом вебе
Google в апреле 2026 года опубликовала исследование о реальном состоянии таких атак на веб-страницах. Команда искала известные признаки непрямого внедрения подсказок в архиве Common Crawl, где ежемесячные снимки охватывают миллиарды страниц англоязычного веба. Сам по себе поиск оказался шумным: многие совпадения пришли из статей, учебников, репозиториев и материалов по безопасности, которые просто объясняли угрозу.
После отсева Google выделила несколько практических категорий. Часть владельцев сайтов просто шутила и пыталась заставить ИИ говорить другим стилем. Часть авторов добавляла подсказки для «правильного» пересказа страницы. Отдельный слой связан с поисковой накруткой: сайт пытается приказать ассистенту хвалить бизнес или направлять пользователя к конкретной компании. Дальше идут попытки отпугнуть ИИ-агентов, например заманить их на страницу с бесконечным потоком текста, чтобы сорвать обработку.
Самый серьезный слой, по данным Google, пока выглядит менее зрелым, но уже заметен. Исследователи нашли небольшое число попыток кражи данных и вредных команд, включая инструкции, которые при реальном выполнении могли бы удалять файлы. Google не увидела массового промышленного применения сложных техник, но зафиксировала рост вредоносной категории на 32% между ноябрем 2025 года и февралем 2026 года. Такой рост важнее разовой страшилки: злоумышленники явно пробуют почву.
Forcepoint X-Labs пошла другим путем и показала десять проверенных нагрузок на живых сайтах. Среди целей были кража ключей, подавление ответа, попытка направить агента к административному пути, поисковая и рекламная подмена, навязчивая атрибуция, уничтожение данных, платежное мошенничество и подмена поведения через фальшивые «системные» метки.
| Где нашли нагрузку | Как прятали | Что пытались сделать |
|---|---|---|
| HTML-комментарии | Текст не виден посетителю страницы | Обратиться напрямую к ИИ и запросить секреты |
| Скрытые блоки CSS | display:none, прозрачный текст, крошечный размер | Подменить пересказ, рекламу или отказ от ответа |
| Служебные метаданные | Псевдосхемы и нестандартные поля | Выдать вредную команду за структурированные данные |
| Разметка доступности | Классы visually-hidden и похожие приемы | Пройти мимо визуальной проверки кода |
| Видимый текст в карточке | Команда среди обычного содержимого | Повлиять на ИИ-помощник разработчика или терминальный агент |
Разница между выводами Google и Forcepoint не обязательно противоречит друг другу. Google смотрит на широкий веб и видит много шума, экспериментов и пока низкую зрелость. Forcepoint показывает, что даже простые приемы уже живут на настоящих доменах и охватывают неприятный спектр целей. Для защитника хватает одного вывода: любая внешняя страница, письмо или документ должны считаться недоверенным входом, даже если человек глазами не видит ничего подозрительного.
Реальные примеры: от страницы в браузере до умного дома
Один из ранних показательных примеров описали Кай Грешаке и соавторы в работе Greshake. Исследователи показали, как страница с внедренной подсказкой могла повлиять на Bing Chat, когда ассистент видел открытый сайт в браузере. Скрытый текст на странице менял поведение ассистента и подталкивал его к социальной инженерии и вытягиванию данных пользователя. Важна не конкретная модель 2023 года, а сам принцип: страница перестала быть просто страницей, когда ассистент начал читать ее как часть задачи.
Позже тот же класс риска проявился в корпоративных помощниках. Самый громкий пример — EchoLeak в Microsoft 365 Copilot. В карточке NVD уязвимость CVE-2025-32711 описана как AI command injection в M365 Copilot, позволяющая неавторизованному атакующему раскрывать информацию по сети. По разбору Aim Labs, внешний отправитель мог доставить вредную инструкцию письмом, а Copilot затем использовал корпоративный контекст и мог передать чувствительные сведения наружу без привычного клика по вложению или запуску программы.
Отдельный тревожный класс показала работа «Invitation Is All You Need» от исследователей из Тель-Авивского университета, Техниона и SafeBreach. В демонстрациях вредные инструкции попадали в календарные приглашения, темы писем и названия документов, после чего Gemini-помощники могли выполнять действия через другие приложения и устройства. Исследователи описали 14 сценариев, включая удаление событий календаря, рассылку, утечку писем, запуск видеосвязи и управление устройствами умного дома.
OpenAI в материале про защиту Atlas приводит еще один понятный сценарий. Браузерный агент читает письмо, где злоумышленник спрятал инструкцию, и может попытаться отправить нежелательное письмо от имени пользователя. Компания прямо признает, что агент в браузере расширяет поверхность атаки, потому что видит страницы и выполняет действия почти в той же среде, где работает человек.
Ассистент получает страницу как контекст и может принять скрытый текст за указание для себя.
Внешнее письмо становится входом для помощника, у которого есть доступ к внутреннему контексту.
Приглашение или название события может нести команду, которую агент прочитает перед действием.
Заметки, отчеты и вложения превращаются в канал влияния на пересказ или дальнейшие действия.
Почему ИИ-агенты меняют масштаб угрозы
Пока модель только отвечает текстом, внедрение подсказок похоже на подмену мнения. Неприятно, но обычно обратимо. Когда модель получает инструменты, риск становится системным. Агент может читать внутренние файлы, искать по почте, открывать ссылки, заполнять формы, менять календарь, писать в рабочие чаты, вызывать программные интерфейсы и запускать команды. Модель превращается в посредника между недоверенным текстом и реальными полномочиями.
Злоумышленнику больше не нужен прямой доступ к жертве. Достаточно попасть в источник, который агент однажды прочитает. В корпоративной среде таким источником может стать письмо от внешнего адресата, заявка в службу поддержки, описание задачи, комментарий к коду, резюме кандидата, документ подрядчика или страница поставщика. В пользовательской среде — календарное приглашение, отзыв, объявление, инструкция на сайте, заметка в общем файле.
ИИ-агент особенно уязвим там, где задача сформулирована широко. Просьба «разбери мои письма и сделай все нужное» дает атакующему много места. Просьба «найди три письма от бухгалтерии за сегодня и составь черновик ответа без отправки» оставляет меньше свободы. Разница кажется бытовой, но для безопасности такая конкретика работает как ремень безопасности.
Какие приемы используют атакующие
Самые простые приемы не требуют редких навыков. Атакующий скрывает текст от человека и оставляет видимым для машинной обработки. Подходы Forcepoint хорошо показывают, что веб давно дает массу укромных мест: комментарии HTML, невидимые блоки CSS, мелкий текст, разметка доступности, служебные поля, поддельные теги, похожие на системные указания.
Более хитрые варианты играют не только с видимостью, но и с доверием. Нагрузка может изображать сообщение от системы, внутреннюю политику, предупреждение об авторском праве, отметку разработчика, служебный токен или структурированные метаданные. Модель склонна уважать инструкции, которые выглядят авторитетно, особенно если внешняя оболочка напоминает системную разметку.
Есть и смысловые атаки, которые сложнее поймать словарем. Вместо грубой команды атакующий пишет письмо как обычную деловую просьбу, где вредное действие выглядит частью рабочего процесса. OpenAI отдельно отмечает, что сильные реальные атаки все больше похожи на социальную инженерию против ИИ-агента, а не на одну очевидную фразу. Модель пытаются не просто обмануть ключевым словом, а втянуть в правдоподобную историю.
- Сокрытие текста через стили страницы.
- Подмена авторитета через фальшивые системные метки.
- Навязывание ссылок, брендов или платежных адресов.
- Попытка вызвать инструмент, который не нужен для задачи пользователя.
- Отравление памяти или длительного контекста, чтобы эффект пережил одну сессию.
- Разделение инструкции на части, чтобы проверка не увидела вред целиком.
Как снижать риск без иллюзии полной защиты
Надежная защита начинается не с красивой подсказки «никогда не слушай злоумышленника». Такая фраза полезна, но не держит удар одна. Нужна архитектура, где внешнее содержимое явно помечено как недоверенное, модель не получает лишних прав, а опасные действия проходят через отдельные проверки. OWASP в разделе LLM01 относит внедрение подсказок к ключевым рискам для приложений на больших языковых моделях и связывает тяжесть последствий с тем, какие полномочия дали модели.
Для разработчиков главный принцип звучит сухо, но спасает нервы: модель не должна быть единственным охранником. Проверки ссылок, прав доступа, форматов ответа, адресатов, сумм платежей, команд терминала и операций с файлами лучше выполнять обычным кодом вне модели. Если модель предлагает действие, внешняя система должна решить, разрешено ли действие в данном контексте.
Для компаний полезен простой набор правил. Не давать агентам постоянный широкий доступ «ко всему». Разделять чтение и действие. Запрашивать подтверждение человека перед письмами, платежами, удалением, изменением прав, выгрузкой данных и переходом на внешние адреса. Вести журнал действий агента. Проверять входящие документы и письма на скрытый текст, подозрительные ссылки и странные служебные поля. Тестировать ИИ-сценарии так же жестко, как веб-приложения и внутренние сервисы.
- Считать сайты, письма, документы, комментарии и названия файлов недоверенным содержимым.
- Не передавать модели секреты, ключи и токены без крайней нужды.
- Запрещать агенту выполнять команды терминала без отдельного подтверждения.
- Ограничивать доступ агента конкретной задачей, временем и набором данных.
- Фильтровать внешние ссылки и не разрешать тихую передачу данных на сторонние адреса.
- Показывать пользователю, какие данные агент собирается отправить или изменить.
- Проводить регулярные проверки с вредными письмами, документами и страницами.
Что делать обычному пользователю
Пользователю не нужно читать исходный код каждой страницы, но стоит перестать воспринимать ИИ-сводку как нейтральную правду. Если ассистент внезапно сообщает о взломе аккаунта, просит позвонить по номеру, перейти по ссылке, срочно оплатить счет или переслать документ, проверяйте первоисточник вручную. Настоящее предупреждение безопасности должно жить в настройках сервиса, а не в пересказе письма, который сгенерировала модель.
Чем больше прав у агента, тем уже должна быть задача. Не «разбери почту и действуй», а «найди письма от конкретного отправителя за сегодня и составь черновик». Не «купи лучший вариант», а «сравни цены без входа в аккаунт и ничего не оплачивай». Не «почини проект», а «объясни проблему и предложи команды, но не запускай их». ИИ хорошо экономит время, но право последнего действия лучше оставлять человеку.
Особенно осторожно стоит включать режимы, где агент работает в уже авторизованном браузере. Если задача не требует личного кабинета, лучше использовать режим без входа. Если агент просит подтвердить письмо, платеж, удаление файла или переход с передачей данных, проверяйте не только красивое объяснение, но и конкретные поля: адресата, ссылку, сумму, список файлов и текст сообщения.
Почему проблема останется с нами надолго
Внедрение подсказок нельзя считать временной детской болезнью ИИ. Проблема растет из самой природы языковых моделей: модель читает язык и пытается следовать смыслу. Для человека тоже нет идеального фильтра от манипуляции, фишинга и приказа, замаскированного под служебную просьбу. С ИИ-агентами похожая история, только скорость выше, масштаб шире, а доступ к данным часто богаче.
Хорошая новость в том, что риск можно сильно уменьшить. Google описывает многоуровневую защиту для Gemini: классификаторы вредных инструкций, усиление системных правил, очистку разметки, удаление подозрительных адресов, подтверждения пользователя и уведомления о срабатывании защиты. OpenAI пишет о проверках, песочницах, подтверждениях, режиме наблюдения и автоматизированном поиске новых атак. Общий смысл один: защищать нужно не одну подсказку, а весь путь от внешнего текста до реального действия.
Плохая новость тоже понятна. Чем полезнее становятся агенты, тем выгоднее атаковать именно агентов. Сайт, письмо или документ больше не просто передают информацию человеку. Для ИИ-системы любой такой объект может стать командной строкой, спрятанной в обычном тексте. Поэтому новая норма звучит жестко, но честно: если агент читает недоверенный контент и умеет действовать, вокруг него нужна полноценная модель угроз, а не вера в аккуратную формулировку системной подсказки.