Искусство обмана: какие уязвимости скрыты в структуре LLM и как выстроить архитектуру защиты

Большие языковые модели стали базовым инструментом в разработке, поддержке пользователей и работе с корпоративной информацией. По мере интеграции LLM с рабочими системами, API и внешними источниками данных усиливаются требования к управлению правами доступа, обработке входных данных и проверке действий ИИ-сервиса.

Сергей Зыбнев, ведущий специалист департамента по работе с уязвимостями информационных систем компании «Бастион», расскажет читателям Кибер Медиа, как в системах с ИИ формируется новая поверхность атаки, почему привычные подходы к безопасности перестают быть достаточно эффективными и как выстроить ИТ-архитектуру, устойчивую к кибератакам.

Где компании используют LLM

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

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

По мере того как модель получает доступ к корпоративным системам, API и внешним источникам данных, меняется и характер рисков. Пока LLM лишь помогают искать информацию или готовить черновые ответы, худшее, что может произойти, — неудовлетворительный результат. Ключевой рубеж — момент, когда модель получает возможность не только формировать ответы, но и выполнять действия через подключенные инструменты и выданные права доступа. В этом случае поверхность атаки расширяется: модель начинает взаимодействовать с внутренними сервисами и сторонними системами, а чем глубже интеграция и шире ее полномочия, тем выше потенциальный ущерб от ошибочных действий.

Почему LLM становятся новой поверхностью атаки

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

Результаты исследований подтверждают чувствительность защитных систем к способу подачи запроса. В работе Adversarial Poetry ручная трансформация вредоносного содержания в стихотворную форму давала 62% успеха в обходе защиты, а автоматическое преобразование увеличивало результативность атаки до 18 раз по сравнению с обычным текстом. В 2025 году фреймворк PRISM Eval, предназначенный для проверки устойчивости коммерческих моделей к хакерским воздействиям, обошел защиту у 37 из 41 протестированных моделей. Эти оценки получены в экспериментальной среде. В прикладных сценариях успех зависит от подготовки атакующего и особенностей интеграции LLM с корпоративными системами и инструментами.

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

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

Главные уязвимости LLM

Большинство инцидентов связано с управлением поведением системы через общий текст обработки. Типовой механизм — контекстная инъекция (prompt injection): специальный фрагмент попадает в рабочую сессию и влияет на ответ или на действия LLM-агента. При прямом варианте атакующие меняют формулировку запроса, используют кодирование или смешивают языки. При косвенном варианте управляющие фразы встраиваются во внешний контент — письма, документы, веб‑страницы — и оказываются в рабочей сессии через подключенные источники.

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

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

Почему традиционная ИБ не работает против LLM

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

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

Дополнительную сложность для систем безопасности создает обработка контекста. Служебные команды, данные из внешних источников и ответы инструментов объединяются в одном потоке. Для традиционных решений это менее предсказуемая среда: они рассчитаны на более четкое разделение ролей и типов трафика. При этом размывается и периметр защиты — LLM-приложения получают данные из API, файлов, писем, веб-страниц и других источников, каждый из которых может стать точкой входа для атаки.

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

Что идет не так на практике

Практика показывает, что компании внедряют LLM в рабочие процессы быстрее, чем успевают выстроить контуры безопасности. Уязвимость EchoLeak (CVE-2025-32711), обнаруженная в 2025 году, показала сценарий компрометации интегрированного ИИ-помощника для работы с документами и другими сервисами. В этом случае встроенная в письмо команда приводила к утечке данных из почты и файлов без действий со стороны пользователя.

В другой цепочке LLM получала данные из облачного хранилища документов и использовала протокол подключения к сервисам — MCP (Model Context Protocol). Скрытая команда заставляла ИИ-агента выполнить вредоносный код и передать злоумышленнику конфиденциальные данные.

Похожие риски проявились и в инструментах для разработки со встроенными ИИ-функциями. В таких системах обнаружили слабые места, которые позволяли выполнять произвольные команды. Через них можно было получить доступ к ключам авторизации и процессам сборки и доставки ПО. Схожие проблемы проявлялись и в корпоративной практике: например, Samsung столкнулась с утечкой исходного кода через ChatGPT, после чего ограничила использование сторонних моделей.

Во всех этих случаях логика атаки схожа. Уязвимость возникает именно в связке компонентов: контекста обработки, внешних данных, инструментов, прав доступа и регламентов, через которые LLM взаимодействует с внутренними системами.

Как выстроить архитектуру защиты LLM

Для LLM нужна многослойная схема защиты. Система не должна получать лишние права: доступ к инструментам и данным ограничивают только тем, что действительно необходимо для задачи. То же касается ИИ-агентов: их изолируют от рабочей среды, а доступ к критическим ресурсам дают через промежуточный слой, который проверяет обращения и ограничивает их частоту.

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

Для критических операций нужен отдельный защитный барьер. Отправка писем, изменение данных и запуск важных процессов не должны выполняться автоматически — действие подтверждает только оператор.

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

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

Проверять нужно и само решение, и всю среду вокруг него: регламенты, внешние базы знаний, цепочки обработки запросов, интеграции и правила доступа. Для этого используют отраслевые рекомендации, например OWASP LLM Top 10 — список ключевых рисков для систем, и регулярные тесты, которые показывают сохранность заданного уровня устойчивости после обновлений.

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