Cryptographic Context Injection: Когда зашифрованные атаки ослепляют защитные барьеры ИИ
Новая атака, систематически ослепляющая фильтры безопасности ИИ
Ландшафт безопасности вокруг больших языковых моделей (LLM) регулярно пополняется новыми уязвимостями — однако последнее открытие компании Adversa знаменует качественный скачок. Под термином Cryptographic Context Injection исследователи описали технику, которая больше не опирается на грубо сформулированные вредоносные инструкции, а использует криптографию: реальные команды атаки передаются в зашифрованном виде и расшифровываются уже внутри среды выполнения модели — в области, недоступной для обычных фильтров безопасности.
Конкретно техника была продемонстрирована против Grok — LLM от xAI. Исследователям удалось вынудить ИИ-ассистента передать пользовательские данные — в том числе имя, местоположение и историю чатов — на внешний сервер. Об атаке компания была уведомлена ещё в июне; на момент публикации уязвимость оставалась незакрытой. Аналогичные векторы также наблюдались против Microsoft 365 Copilot и Google Gemini, что наглядно подчёркивает масштаб проблемы.
Как работает Cryptographic Context Injection с технической точки зрения
Чтобы понять масштаб проблемы, стоит разобраться в механизме: классические атаки типа Prompt-Injection внедряют вредоносные инструкции в контент, который ИИ-ассистент должен обработать, — например, в электронные письма или веб-страницы, которые модель должна резюмировать. LLM структурно не способны надёжно различать, исходит ли инструкция от авторизованного пользователя или от манипулированного документа. Это не ошибка, а фундаментальное свойство парадигмы обучения: модель оптимизирована на выполнение инструкций.
Существующие контрмеры опираются на так называемые статические фильтры безопасности (Guardrails), которые проверяют входящие и исходящие тексты на наличие подозрительных паттернов. Именно здесь и вступает в действие Cryptographic Context Injection:
- Злоумышленник размещает зашифрованный вредоносный код (шифртекст) на веб-странице — вместе с ключом расшифровки и инструкцией расшифровать этот код.
- ИИ-ассистент получает безобидное задание — резюмировать страницу.
- Модель самостоятельно выполняет расшифровку в своей песочнице выполнения кода — с использованием алгоритмов PBKDF2 и AES-256-GCM.
- Фильтр безопасности ни в какой момент не видит открытый текст вредоносной инструкции, поскольку он не исполняет код, а лишь классифицирует текст.
- Расшифрованные инструкции поступают в модель как её собственный вывод инструмента (Tool-Output) — и выполняются без какой-либо дополнительной проверки.
Ключевая фраза исследователя Adversa Рони Утевского точно формулирует суть проблемы:
„Static safety guardrails classify inputs as text; they do not execute them. An attacker ships ciphertext along with the key material and an instruction to decrypt it, and the model runs that decryption inside its own code execution sandbox."
Тому, чего не хватает сканерам Guardrail, — это способности к динамической интерпретации кода в момент проверки. Вредоносная нагрузка зашифрована и невидима — до тех пор, пока сама модель не делает её видимой.
Почему это структурная проблема, а не проблема конкретного продукта
Было бы удобно списать эти инциденты на сбои отдельных поставщиков. На самом деле они обнажают системную слабость: LLMs не способны самостоятельно решить корневую проблему Prompt Injections. Это обусловлено их архитектурой. Каждый новый подход к Guardrails устраняет конкретный вектор атаки — и тем самым имплицитно создаёт условия для того, чтобы злоумышленники разработали следующий.
Adversa точно характеризует эту взаимосвязь как смещение вектора атаки: уже не сам Prompt, а весь контекст, который LLM воспринимает как собственную среду — Tool-Outputs, результаты выполнения, промежуточные состояния — становится поверхностью атаки. Она несопоставимо больше того, что традиционно считается «входными данными модели».
Dr. Maik Bunzel, основатель и генеральный директор mabucon.eu, подчёркивает в этой связи, что компании, интегрирующие KI-агентов в операционные процессы, должны активно учитывать это структурное свойство в своей архитектуре рисков: вопрос безопасности — это не только вопрос выбранной модели, но и системной архитектуры вокруг неё — включая данные, к которым агент имеет доступ, и действия, которые он вправе выполнять самостоятельно.
Последствия для компаний с KI-автоматизацией
Для организаций, интегрирующих KI-ассистентов и агентов в свои рабочие процессы — будь то управление электронной почтой, обработка документов или коммуникация с клиентами — из этих выводов вытекают конкретные направления действий:
- Principle of Least Privilege для KI-агентов: агенты должны иметь доступ только к тем данным и системам, которые абсолютно необходимы для их конкретной задачи. Широкие права доступа к данным многократно увеличивают потенциальный ущерб от успешных атак типа Prompt Injection.
- Human-in-the-Loop для чувствительных действий: действия с внешними эффектами — отправка электронных писем, обращение к внешним URL, передача данных — должны требовать явного подтверждения, которое не может быть преодолено самой моделью.
- Недоверие к внешнему контенту как принцип проектирования: любой контент, который KI-агент обрабатывает из интернета или из пользовательских документов, должен с точки зрения системной архитектуры рассматриваться как потенциально враждебный — а не как надёжное расширение задания пользователя.
- Мониторинг и обнаружение аномалий: поскольку Guardrails в одиночку не обеспечивают полной защиты, возрастает значение последующего контроля поведения агентов: какие внешние соединения устанавливает агент? Какие данные покидают систему?
- Vendor-Due-Diligence и циклы обновлений безопасности: тот факт, что xAI на протяжении нескольких месяцев после сообщения об уязвимости не предоставил решения, наглядно показывает: при выборе поставщика компаниям следует обращать внимание и на скорость реагирования на сообщения об уязвимостях.
Игра в кошки-мышки и что она означает для отрасли KI
Аналогия, которую используют исследователи безопасности, весьма показательна: инженер по безопасности дорожного движения устанавливает отбойники на опасном повороте — вместо того чтобы выпрямить сам поворот. Каждый новый отбойник — это реакция на последнюю аварию; сам поворот остаётся опасным. В случае LLM поворотом является фундаментальная неспособность надёжно разделять контекст и намерение.
Это не означает, что KI-агенты и ассистенты не могут применяться продуктивно и безопасно. Однако это означает, что безопасность здесь достигается не за счёт доверия к модели, а посредством архитектурного контроля вокруг модели. Dr. Maik Bunzel, основатель и генеральный директор mabucon.eu, видит в этом ключевую задачу проектирования на ближайшие годы: создавать KI-системы так, чтобы их свойства безопасности зависели не от совершенства отдельного Guardrails, а обеспечивались избыточными, системными средствами контроля.
Cryptographic Context Injection в этом отношении — не исключение, а ориентир. Сама Adversa формулирует это точно: следующее поколение атак возникнет именно там, где LLMs обрабатывают внешние Tool-Outputs, результаты выполнения и промежуточные состояния как часть собственного контекста. Тем, кто сегодня интегрирует KI-агентов в производственные системы, следует знать эту поверхность атаки и адресовать её на архитектурном уровне.
Заключение: безопасность как системное проектирование, а не как характеристика продукта
Обнаружение Cryptographic Context Injection свидетельствует о зрелости, которую необходимо признать за атакующей стороной в экосистеме LLM: они мыслят уже не промптами, а системами. Защищающаяся сторона — и это в явной мере относится к компаниям, использующим KI-продукты, — должна сделать тот же шаг. Безопасность в эпоху KI — это не функция, которую поставляет поставщик модели. Это системное свойство, возникающее благодаря осознанному проектированию и требующее постоянного осмысления быстро развивающегося ландшафта угроз.