Команда исследователей, представившая работу на Международной конференции по машинному обучению (ICML), утверждает: полная защита больших языковых моделей от атак невозможна из-за свойства, заложенного в самой архитектуре. Модель не способна надёжно отличать данные от инструкций - и именно на этом строится prompt injection. Разбираем, что стоит за аргументом и какие следствия он имеет для бизнеса, который внедряет LLM в рабочие процессы.

В чём суть фундаментального недостатка

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

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

Как устроены атаки на LLM

Основной класс атак во время инференса - манипуляция входным промптом. Атакующий подбирает формулировку так, чтобы модель вышла за пределы заданного поведения. Две самые распространённые цели таких атак - jailbreak (обход фильтров безопасности и получение ответа, который модель не должна давать) и prompt leaking (извлечение системного промпта, то есть скрытых инструкций разработчика).

Атаки усложняются: появляются многоагентные фреймворки, где prompter LLM генерирует варианты промптов, attacker LLM отправляет их целевой модели, а scorer LLM оценивает успешность. Вся схема работает с обучаемой «attack memory», которая хранит удачные и неудачные попытки и формирует всё более точные инъекции. Это уже не ручной подбор - это автоматизированный поиск уязвимостей, и он масштабируется быстрее, чем ручной аудит.

Почему стандартная защита работает только частично

Разработчики LLM используют два основных механизма. Alignment - дообучение модели, чтобы её ответы соответствовали заявленным ценностям и ограничениям. Guardrails - системы реального времени, которые фильтруют вредоносные или нежелательные ответы прямо в момент генерации. Дополнительно компании привлекают команды red-team - людей-тестеров, которые целенаправленно ищут слабые места, и используют LLM-«суперхакеров» вроде GPT-Red у OpenAI для автоматизации такого поиска.

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

Дополнительные векторы: RAG и агенты

Уязвимости LLM не ограничиваются пользовательским вводом. Модели, использующие Retrieval Augmented Generation (RAG), читают внешние источники перед тем, как сформировать ответ. Если атакующий может подменить или внедрить контент в этот источник - например, в статью в корпоративной базе знаний или в документ, к которому модель обращается, - он получает возможность вставить вредоносные инструкции прямо в ответ модели. Защита на стороне пользовательского промпта здесь не помогает: заражён сам контекст, который модель считает надёжным.

Отдельный класс рисков появляется, когда LLM встраивается в автономные агентские системы. Такие агенты умеют ставить цели, планировать действия и вызывать внешние инструменты - отправлять письма, обращаться к API, работать с файлами. Успешная инъекция превращается в вектор для кражи, удаления или порчи корпоративных данных: модель сама выполняет деструктивное действие, потому что «думает», что получила корректную инструкцию.

Что это значит для бизнеса

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

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

Итог

Аргумент исследователей с ICML сводится к одному: уязвимости LLM - это не дефект, который можно устранить доработкой, а следствие архитектурного принципа. Защищать модель нужно не «внутри», а вокруг - через архитектуру приложения, контроль доступа и ревизию данных, к которым модель обращается.

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