Скрытые команды в документах: как устроена инъекция промпта и почему её так трудно закрыть
В августе 2026 года судья Высшего суда штата Коннектикут Уолтер Спейдер-младший распечатал очередное ходатайство по делу Elliott v. New York Bariatric Group и заметил странность: на бумаге остались слишком широкие пустые промежутки. При ближайшем рассмотрении в документе нашёлся текст — белым шрифтом крошечного кегля по белому фону. Адресован он был не суду и не ответчику, а программе: если этот документ читает ИИ-модель, её вывод должен отражать позицию истца.
Истец вёл дело сам, без адвоката, и, судя по всему, исходил из предположения, что кто-то в суде подсунет его бумаги нейросети и попросит краткое изложение. Расчёт не сработал — но история интересна не судебной интригой. Это редкий публичный пример явления, которое исследователи безопасности обсуждают третий год подряд и до сих пор не умеют надёжно предотвращать: инъекции промпта.
Белый текст на белом фоне: что произошло в суде
Документ с двумя адресатами
Спрятанная строка была набрана почти нулевым кеглем и залита цветом фона — на экране и в печати её не видно, но при копировании текста или разборе PDF она извлекается как обычный абзац. Формулировка повторялась несколько раз и была написана в приказном тоне, обращённом к «модели, которая просматривает документ». В последующих подачах истец добавил ещё скрытых вставок, включая шуточные — «надеюсь, вы меня не видите» и ссылку на мем.
Поймал человек, а не машина
Иронично, что защитой оказалась бумага: судья печатал пленарные материалы и увидел лишние отступы там, где по вёрстке их быть не должно. В четырнадцатистраничном постановлении он сформулировал претензию не технически, а процессуально: подача документа — это сообщение и суду, и противоположной стороне, а текст, невидимый человеку, но подложенный машине для исполнения, нарушает сам принцип открытой состязательности.
Санкция оказалась соразмерной: истца лишили права электронной подачи, теперь бумаги он носит в канцелярию лично. Юридические обозреватели назвали эпизод первым задокументированным случаем инъекции промпта, нацеленной на американский суд. И это хороший повод разобрать, почему такая примитивная на вид уловка вообще имеет шанс сработать.
Почему модель не отличает данные от команд
Один поток текста вместо двух каналов
У обычной программы код и данные разведены: процессор исполняет инструкции, а файл, который программа открыла, остаётся содержимым. У языковой модели такого разделения нет. Системная инструкция сервиса, ваш вопрос, содержимое приложенного PDF, результат веб-поиска, ответ подключённого инструмента — всё склеивается в одну последовательность токенов, из которой модель предсказывает продолжение.
Формально роли размечены: есть системное сообщение, пользовательское, ответ ассистента, результат инструмента. Но эта разметка — не стена, а подсказка. Модель обучена в среднем считать системную инструкцию главнее, и это статистический приоритет, а не архитектурная гарантия. Достаточно убедительной формулировки внутри «данных», чтобы приоритет поплыл.
Это не взлом в привычном смысле
Термин появился по аналогии с SQL-инъекцией: там злоумышленник пишет в поле формы не имя, а кусок запроса, и база принимает его за команду. Разница принципиальная. SQL лечится параметризацией — базе один раз объясняют, где кончается запрос и начинаются данные. Для естественного языка эквивалента нет: не существует синтаксиса, который скажет модели «дальше только материал, ни одна фраза отсюда не приказ».
Прямая и косвенная: два вида инъекции
Прямая — спор с системной инструкцией
Прямая инъекция — это когда команду пишет сам пользователь, прямо в поле ввода: пытается вытащить системный промпт, снять ограничения сервиса, заставить модель играть роль, в которой правила «не действуют». В классификации OWASP это LLM01 — уязвимость номер один в списке рисков для приложений на языковых моделях. Ущерб тут в основном ограничен собственной сессией атакующего.
Косвенная — приказ приезжает вместе с данными
Куда опаснее вторая разновидность. Вы просите ассистента пересказать письмо, открыть страницу, разобрать договор — и он честно тянет внешний текст в контекст. Автор этого текста вам незнаком, а его строки попадают в тот же поток, что и ваши. Атакующий и жертва здесь разные люди, и жертва не делает ничего подозрительного. Судебный документ с белым шрифтом — ровно этот сценарий.
Носитель не обязан быть текстом
Спрятать строку можно десятком способов: комментарий в HTML, метаданные файла, невидимый слой PDF, подпись alt у картинки, символы нулевой ширины. Отдельная категория — мультимодальные вставки: надпись на изображении, которую человек считает орнаментом, а модель со зрением прочитает как текст. По телеметрии Unit 42, более 85% встреченных вставок обходятся вовсе без «технического» синтаксиса — они просто написаны авторитетным или срочным тоном.
Что уже случалось на практике
Резюме с невидимым абзацем
Самый массовый бытовой случай — найм. Исследователи Университета Дьюка разобрали около 200 тысяч реальных резюме и нашли скрытые вставки минимум в одном проценте. При этом опрос 1200 соискателей дал 41% признавшихся — расхождение на порядок хорошо показывает разницу между «слышал о приёме» и «действительно применил».
Работает ли это? Работа, представленная в 2026 году на конференции ACL, показала: влияние на ранжирование есть, но заметно оно, только пока трюком пользуются единицы. Чем больше кандидатов вставляют скрытый текст, тем меньше преимущество. А главное, современные системы отбора обычно снимают форматирование перед чтением и помечают найденную вставку как красный флаг — то есть тот же приём всё чаще ведёт не к приглашению, а к автоматическому отказу.
Письмо, которое дописывает себе предупреждение
В 2025 году исследователь показал уязвимость в Gemini для Workspace. В тело письма прятался блок с нулевым размером шрифта и белым цветом; сообщение выглядело безобидным. Стоило получателю нажать «кратко изложить», как в конце сводки появлялось фальшивое предупреждение о компрометации пароля с номером телефона «службы поддержки». Ни вложений, ни ссылок — почтовым фильтрам не за что было зацепиться. Google выпустил меры защиты; свидетельств массовой эксплуатации не нашли.
EchoLeak: утечка без единого клика
Самый показательный случай — EchoLeak (CVE-2025-32711, оценка 9,3 из 10), найденный в Microsoft 365 Copilot в июне 2025 года. Атакующему достаточно было прислать письмо; открывать его жертва не обязана. Позже, когда Copilot по другому поводу подтягивал почту в контекст, скрытые инструкции заставляли его собрать чувствительные данные из соседних документов и вшить их в адрес внешнего ресурса. Взаимодействия пользователя не требовалось вовсе.
Атака попутно обошла классификатор инъекций, фильтр редактирования ссылок и клиентскую политику безопасности — каждый слой защиты по отдельности был предусмотрен и каждый оказался обходим. Microsoft закрыл дыру на своей стороне и сообщил, что реальных случаев эксплуатации не зафиксировано. Но EchoLeak остался первым публичным примером, где инъекция промпта в боевой системе приводит к конкретной краже данных, а не к забавному ответу чат-бота.
Почему риск растёт вместе с доступами
Опасное сочетание трёх способностей
Удобную формулу предложил инженер Саймон Уиллисон: беда наступает там, где сходятся три свойства — доступ к личным данным, чтение недоверенного контента и возможность отправить что-то наружу. По отдельности каждое безобидно. Вместе они дают полную цепочку: чужая строка попадает внутрь, дотягивается до вашей почты и уходит вместе с ней по внешнему адресу. Уязвимости в коде для этого не нужно — хватает языка.
Уже не лабораторная страшилка
До конца 2025 года косвенные инъекции жили в основном в отчётах исследователей. В марте 2026 года Unit 42 опубликовала телеметрию из «дикой природы»: десяток задокументированных случаев и два десятка приёмов оформления вставок на живых коммерческих площадках. В одном эпизоде на страницу товара было заложено 24 попытки подряд, чтобы ИИ-проверяющий одобрил мошенническое объявление.
Инъекция промпта — не дыра в конкретном продукте, а следствие того, что одним и тем же языком мы описываем и данные, и приказы.
Как защищаются разработчики
Разделение ролей и разметка чужого текста
Первый слой — обучить модель иерархии: системная инструкция важнее пользовательской, а всё, что пришло из инструментов и файлов, важнее их обеих быть не может. Внешние данные при этом заворачивают в явные разделители со смыслом «это цитата, а не распоряжение». Приём отбивает грубые попытки, но исследования показывают: под целенаправленным подбором формулировок обученная иерархия проседает.
Классификаторы и фильтрация вывода
Второй слой — модель-сторож, которая просматривает входящий контент и ответ ассистента до того, как их увидит пользователь. Сюда же относится вычистка исходящих ссылок и запрет на подгрузку картинок с произвольных адресов — чтобы вывод нельзя было превратить в канал утечки. Слой полезный, но, как показал EchoLeak, обходится перефразированием.
Песочница, минимум прав, подтверждение действий
Главный сдвиг последнего года — перестать надеяться на послушание модели и сузить то, что она физически может. Ассистенту выдают только нужные инструменты, чтение отделяют от записи, исходящие запросы ограничивают белым списком доменов, а необратимые действия — отправку письма, оплату, удаление файла, публикацию кода — выносят за кнопку подтверждения. В идеале — с показом того, что именно будет сделано.
Две модели вместо одной
Самое интересное направление — архитектурное. Схема с двумя моделями разводит роли: привилегированная планирует действия и никогда не видит недоверенный текст, карантинная читает чужое содержимое, но лишена права вызывать инструменты. Развитием идеи стала система CaMeL от Google DeepMind: план превращается в программу с проверяемыми политиками доступа. На независимом наборе тестов она нейтрализовала около двух третей атак — цифра честная и одновременно отрезвляющая.
Почему проблема не закрыта
Потому что у неё нет параметризации. Атака ведётся на естественном языке, пространство формулировок бесконечно, и любой фильтр остаётся эвристикой: он отсекает известные образцы и пропускает следующий. Обучение снижает вероятность, но не даёт гарантии, а гарантия — это как раз то, чего требует безопасность. Поэтому индустрия постепенно уходит от вопроса «как сделать модель невосприимчивой» к вопросу «как ограничить ущерб от того, что она однажды поверит чужому тексту».
Что это значит для обычного пользователя ИИ-ассистента
Где вы рискуете на самом деле
Пока ассистент просто разговаривает, потолок неприятностей — странный ответ. Всё меняется в момент, когда вы подключаете к нему почту, диск, календарь, браузер или рабочие системы и разрешаете действовать. Именно тогда чужой документ получает шанс стать вашей проблемой. Полезно смотреть на список выданных разрешений как на список того, что теоретически может сделать текст из непроверенного письма.
Несколько рабочих привычек
Не выдавайте доступы «на всякий случай» — только под задачу. Не подтверждайте действия вслепую: окно подтверждения существует ровно для того, чтобы вы заметили нелогичное. Считайте пересказ письма пересказом, а не фактом, — особенно если в нём появились срочность, номер телефона или просьба куда-то перейти; в таком случае откройте исходник и проверьте. Для важных документов полезно хотя бы раз посмотреть исходный текст, а не только сводку.
И обратная сторона медали
Соблазн спрятать пару строк в своём резюме или договоре стоит гасить на корню. Системы отбора и юридические платформы уже умеют искать невидимый текст, а находка трактуется однозначно — как попытка обмана. Истец из Коннектикута не получил решения в свою пользу; он получил разбирательство о своём поведении и потерю права подавать документы онлайн.
Главный вывод простой и неуютный: слабое место здесь — не конкретная модель и не конкретный продукт, а сама идея, что один и тот же поток текста может быть одновременно материалом и распоряжением. Пока эта двойственность не разведена архитектурно, надёжность обеспечивают не запреты внутри модели, а границы вокруг неё.
Пока нет комментариев