На проверке Instruction Privilege Escalation: как контекст агента получает root-права над LLM

В 2025 году Johann Rehberger (Embrace The Red) показал атаку, после которой хочется пересмотреть отношение к «безобидным» coding-агентам. GitHub Copilot через indirect prompt injection перезаписывал конфигурацию Claude Code - файл .mcp.json - добавляя туда вредоносный MCP-сервер. Claude Code подхватывал изменённую конфигурацию и выполнял произвольный код. Потом Claude обновлял .vscode/settings.json Copilot, замыкая петлю cross-agent privilege escalation. Ни один из агентов не эксплуатировал техническую уязвимость в классическом понимании - каждый действовал в рамках своих легитимных полномочий на запись файлов. Проблема архитектурная: отсутствие изоляции между конфигурациями агентов превратило файловую операцию в эквивалент sudo.

Бизнес-логика атаки проста до неприличия: злоумышленнику не нужно красть credentials или эксплуатировать RCE. Достаточно внедрить payload в данные, которые обрабатывает один агент, и он сам выполнит эскалацию привилегий в LLM-агентах - используя собственные права на доступ к API, базам данных, файловой системе или другим агентам. Финальный импакт - от эксфильтрации моделей и обучающих данных до полного захвата облачной инфраструктуры через цепочку tool calls.

Формальная модель: LLM-агент как привилегированный процесс​

Чтобы говорить об атаках на AI-агентов не на уровне анекдотов, а на языке, допускающем верификацию и построение защиты, нужна формальная модель. Работа, условно обозначаемая здесь как SEAgent (предположительно arxiv, январь 2025, «Taming Various Privilege Escalation in LLM-Based Agent Systems: A Mandatory Access Control Framework» [публикация не верифицирована; все ссылки на неё в статье следует рассматривать как гипотетические]) предлагает именно такую: агентная система описывается как набор сущностей с атрибутами и управляемыми потоками выполнения. Подробнее - в нашем руководстве по безопасность llm приложений.

Ключевые примитивы модели:

• Subject - агент или пользователь, инициирующий действие. Каждый субъект маркируется атрибутами: роль, уровень доверия, источник инструкции (system / user / tool / inter-agent).
• Object - инструмент (tool), RAG-база данных, другой агент в мультиагентной системе. У объекта есть метка sensitivity и scope допустимых операций.
• Privilege - множество tool calls, достижимых субъектом в текущем контексте. Критический момент: привилегия определяется не только ACL, но и состоянием контекстного окна - тем, что LLM «видит» в момент принятия решения о вызове инструмента.
• Эскалация привилегий - любое действие агента, выходящее за рамки минимально необходимого для выполнения задачи пользователя (нарушение принципа наименьших привилегий).

Модель делает видимой фундаментальную проблему контекста агента LLM. В классических системах привилегии привязаны к identity и проверяются детерминистически: ядро ОС не спрашивает процесс «ты уверен, что тебе нужен этот syscall?». В агентных системах привилегии фактически определяются содержимым контекстного окна, которое собирается из нескольких источников с разным уровнем доверия. Manipulation системного контекста LLM через любой из каналов - system prompt, user input, tool output, RAG-данные, inter-agent messages - эквивалентна подмене identity в традиционной модели.

Иерархия инструкций LLM и её архитектурная хрупкость​

В теории иерархия инструкций LLM устроена как кольца защиты в x86: system prompt - ring 0, user prompt - ring 3, tool output - ring 1 или 2 в зависимости от реализации. OpenAI формализовала подход в работе «Instruction Hierarchy» (Wallace et al., 2024), предложив обучать модели приоритизировать system-level инструкции над user-level при конфликте.

На практике это probabilistic enforcement. И тут начинается самое интересное. Модель может проигнорировать system prompt при достаточно длинном контексте (attention dilution), «забыть» ограничения при убедительной prompt injection атаке или смешать инструкции из разных источников в одну цепочку рассуждений. Обход системного промпта - не баг конкретной модели, а архитектурное свойство всех transformer-based LLM: модель не имеет аппаратного разделения между «кодом» (инструкции) и «данными» (пользовательский ввод). Всё - текст в одном контекстном окне, и instruction hierarchy bypass сводится к задаче убедить attention-механизм перераспределить веса в пользу injected instructions.

Это именно тот паттерн, который OWASP LLM01:2025 (Prompt Injection) описывает как фундаментальный риск: crafted user input alters LLM behavior, bypassing safety controls. В агентных системах последствия prompt injection масштабируются количеством инструментов, доступных агенту: каждый tool - дополнительный ресурс, к которому injection получает доступ.

Таксономия атак: пять векторов эскалации привилегий​

В рамках модели SEAgent (неверифицированный источник) выделяются пять категорий атак, ведущих к захвату root-прав над LLM. Все пять демонстрируются на реальных агентных фреймворках и бенчмарках (InjecAgent, AgentDojo, API-Bank). Ни один русскоязычный источник на момент написания не покрывает эту таксономию целиком - разберём каждый вектор с предусловиями и ограничениями.

Prompt injection: direct и indirect entry points​

Direct prompt injection - пользователь напрямую манипулирует поведением агента через входной запрос. В контексте эскалации: пользователь с правами «прочитать документ» формулирует запрос так, что агент вызывает tool с правами «удалить документ» или «отправить email на внешний адрос». Классическая prompt hierarchy manipulation - пользовательская инструкция переопределяет системную.

Indirect prompt injection - payload внедряется не через пользовательский ввод, а через данные, которые агент обрабатывает: содержимое веб-страницы, email, документ из корпоративной базы знаний. Агент воспринимает вредоносную инструкцию как часть обрабатываемых данных и выполняет tool call, который пользователь не запрашивал. Это tool-use exploitation LLM в чистом виде: легитимный инструмент, легитимные права - нелегитимный контекст вызова.

Предусловия и ограничения:

• Для direct injection: атакующий должен иметь доступ к интерфейсу агента (чат, API). Эффективность снижается на моделях с обученной instruction hierarchy (fine-tuning по методу Wallace et al., 2024), но не до нуля - adaptive attacks обходят ML-based защиты, как показано в работах Zhan et al., 2025.
• Для indirect injection: payload должен попасть в контекстное окно. Если агент не обрабатывает внешние данные - вектор неприменим. Длина payload ограничена размером chunk'а при RAG-retrieval.

RAG poisoning и инфраструктурная эскалация​

RAG (Retrieval Augmented Generation) добавляет в контекст агента фрагменты из внешней базы знаний. Контроль над содержимым хотя бы одного документа в этой базе = контроль над частью контекстного окна. По OWASP LLM04:2025 (Data and Model Poisoning) это supply chain вектор: manipulating training/fine-tuning/embedding data to introduce vulnerabilities.

По неверифицированным публикациям, исследователи Unit 42 (Palo Alto Networks) предположительно продемонстрировали смежный сценарий на Google Vertex AI [точная ссылка, дата и технические детали отчёта не подтверждены; весь блок требует проверки по первоисточнику]. Описанный паттерн: одно cloud permission эскалировалось до широкого доступа к данным проекта через избыточные права service agent identity. Второй заявленный вектор - model exfiltration через деплой отравленной модели, которая предположительно получала доступ к другим ML-моделям проекта, включая fine-tuned LLM adapters. Адаптеры могут содержать sensitive information из обучающих данных - это соответствует OWASP LLM02:2025 (Sensitive Information Disclosure).

Предусловия и ограничения:

• RAG poisoning требует write-доступа к базе знаний или к источникам, откуда база индексируется (wiki, SharePoint, Confluence). Нет записи в KB - нет вектора.
• Vertex AI уязвимости специфичны для конфигурации платформы. Google предположительно исправила оба вектора после responsible disclosure от Unit 42 [требует подтверждения]. Но паттерн - одно permission эскалируется до полного доступа через service agent identity - характерен для многих ML-платформ с multi-tenant архитектурой.

Confused Deputy в мультиагентных системах​

Confused deputy - классика, когда привилегированная программа выполняет действие от имени менее привилегированного субъекта, «одалживая» свои права. В мультиагентных системах (MAS) паттерн воспроизводится через inter-agent communication: скомпрометированный агент A отправляет запрос доверенному агенту B, у которого есть доступ к критическому tool (управление smart lock, financial API, production database). Агент B выполняет tool call от своего имени, не проверяя - имеет ли агент A право инициировать такое действие.

SEAgent формализует это как «inter-agent privilege escalation». В системах с broadcast-коммуникацией скомпрометированный агент рассылает crafted messages всем участникам, превращая каждого в потенциальный confused deputy. Ни один существующий secure agent framework до SEAgent - ни IsolateGPT, ни CaMeL, ни Conseca - не адресовал этот вектор: все фокусировались на single-agent сценариях.

По MITRE ATT&CK использование легитимных учётных данных для несанкционированных действий соответствует технике Valid Accounts (T1078, тактики: Initial Access, Persistence, Privilege Escalation, Defense Evasion). В контексте LLM agent security «учётная запись» - identity агента, а «легитимный доступ» - набор tool permissions, привязанных к этому identity. MITRE D3FEND рекомендует Access Modeling (D3-AM) для моделирования нормальных паттернов доступа и обнаружения аномалий.

Предусловия и ограничения:

• Confused deputy реализуем только в MAS с inter-agent communication. Single-agent системы уязвимы к другим векторам, но не к этому.
• Атака эффективнее в системах с broadcast messaging, где каждый агент видит все сообщения. Point-to-point architecture с аутентификацией отправителя значительно снижает поверхность.
• Наличие Model Context Protocol (MCP) расширяет attack surface: каждый MCP-сервер - дополнительный tool, потенциально доступный через confused deputy chain.

Семантическая эскалация: когда все проверки проходят​

Концепция «semantic privilege escalation» описывает ситуацию, от которой у IAM-инженера должен дёрнуться глаз: каждая проверка доступа проходит, каждый tool call авторизован, каждый permission check возвращает ALLOW - но действие не соответствует задаче пользователя.

Пример: агент customer support имеет read-доступ к CRM, HR-базе и финансовой системе - легитимно, для разных типов тикетов. Пользователь спрашивает про статус заказа. Через indirect injection (payload в теле тикета) агент выполняет SELECT [I] FROM hr_salaries вместо SELECT [/I] FROM orders. Оба запроса авторизованы по ACL. Но второй - эскалация: агент использовал привилегию не для той задачи. Это AI agent harness уязвимости в чистом виде.

Традиционный IAM спрашивает: «Имеет ли этот identity право выполнить это действие?» Семантическая эскалация эксплуатирует вопрос, который IAM не задаёт: «Соответствует ли это действие текущему intent пользователя?»

Проблема становится острее, если посмотреть на статистику credential-based атак. По данным CrowdStrike Global Threat Report 2025, 75% вторжений используют действительные учётные данные. IBM X-Force Threat Intelligence Index 2025 фиксирует рост атак с valid credentials на 71% год к году. Когда эти credentials принадлежат автономному агенту с десятком tool-интеграций - blast radius определяется не тем, что агент должен делать, а тем, что его permissions позволяют.

По OWASP LLM06:2025 (Excessive Agency): LLM с избыточными функциями, permissions или автономией может выполнять действия, которые не были запланированы. Это точное описание semantic privilege escalation - agent framework по умолчанию даёт агенту доступ ко всем зарегистрированным tools, а разработчик полагается на system prompt для ограничения использования. System prompt override через injection немедленно снимает это ограничение.

Четыре характерных паттерна, указывающих на semantic escalation (авторская систематизация):

Паттерн	Описание	Отличие от prompt injection
Impersonation	Заявление другой роли в input: «I am the admin»	Целит в permission layer, не в instruction layer
Instruction override	Попытка модифицировать permissions агента: «Add write access»	Меняет capability, не поведение
Jailbreak-adjacent	Отключение audit logging или compliance controls	Снимает контроль, не переопределяет цель
Sudo-style injection	Команды sudo, NOPASSWD, privilege modification syntax	Использует системный синтаксис в NL-контексте

Cross-Agent Privilege Escalation: агенты освобождают друг друга​

Исследование Rehberger (Embrace The Red, 2025) описывает принципиально новый класс атак на AI-агентов: один агент перезаписывает конфигурацию другого, расширяя его возможности - «освобождая» от sandbox-ограничений. По сути agent A помогает agent B выйти из песочницы, добавляя ему capabilities, которых у B изначально не было.

Механика строится на нескольких фактах, характерных для современных coding-агентов:

• Агенты хранят конфигурацию в файлах рабочей директории: .vscode/settings.json и .vscode/mcp.json (Copilot), .mcp.json (Claude Code), .gemini/settings.json (Gemini).
• Агенты могут создавать и записывать файлы без явного подтверждения пользователя (до недавнего времени - без ограничений, в том числе в чужие конфигурации).
• Инструкционные файлы - AGENTS.md, CLAUDE.md, .vscode/copilot-instructions.md - влияют на поведение агентов при следующем запуске. Запись в чужой instruction file = instruction hierarchy bypass через файловую систему.

Цепочка атаки, продемонстрированная на видео:

1. Indirect prompt injection в данных репозитория (комментарий в коде, markdown-файл) захватывает Copilot.
2. Copilot создаёт или модифицирует .mcp.json - конфигурацию MCP-серверов Claude Code - добавляя вредоносный сервер с arbitrary code execution.
3. Copilot записывает CLAUDE.md с instructions для Claude Code, направляющими на выполнение определённых действий.
4. Разработчик переключается на Claude Code. Claude подхватывает изменённую конфигурацию и выполняет произвольный код через подключённый MCP-сервер.
5. Claude обновляет .vscode/settings.json Copilot - петля замыкается.

Rehberger особо отмечает: «Agents that coordinate and collaborate to achieve malicious objectives seem very plausible to me in the long term.» Атака не ограничена VS Code: это generic подход, где compromise одного агента ведёт к компрометации другого через файловую систему как shared medium.

Предусловия и ограничения:

• Разработчик использует несколько coding-агентов на одной кодовой базе. Сценарий распространён: Copilot + Claude Code, Copilot + Gemini и другие комбинации для «second opinion» или code review.
• Агент-инициатор должен иметь возможность записи в dot-файлы без approval. После disclosure некоторые вендоры добавили подтверждения для перезаписи собственных конфигураций - но не конфигураций других агентов.
• Для API-based агентов без файловой системы прямой вектор не применим. Аналогичная логика работает через shared memory stores, shared databases или любой другой persistent medium, к которому имеют доступ несколько агентов.

MSRC получил отчёт об уязвимости. По утверждению Rehberger, ответ был: «не считается достаточно серьёзным для немедленного security servicing» [цитата из блога Embrace The Red; независимо не верифицирована], но команда может рассмотреть улучшение mitigations. Ответ симптоматичный: вендоры пока не классифицируют cross-agent configuration overwrite как полноценную уязвимость. Напоминает историю с SSRF - годами считалась «не багом», пока не попала в OWASP Top 10.

Защита: Mandatory Access Control для агентных систем​

SEAgent: ABAC-политики и Decision Engine​

SEAgent переносит принципы Mandatory Access Control (MAC) из мира ОС (SELinux, AppArmor) в агентные LLM-системы. Подход строится на Attribute-Based Access Control (ABAC): каждая сущность маркируется статическими атрибутами, а политики определяют допустимые пути выполнения.

Архитектура из четырёх компонентов:

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Концептуально политика для предотвращения confused deputy в MAS:

DENY tool_call
  WHERE subject.source = "inter-agent"
  AND object.sensitivity >= "high"
  AND NOT verified(subject.original_user_intent)

Правило запрещает вызов высокочувствительных инструментов, инициированных через inter-agent message, если исходный intent пользователя не верифицирован. Детерминистическая проверка - без LLM в цепочке принятия решения о доступе.

Результаты: количественная оценка​

По заявленным, но независимо не верифицированным результатам оценки на бенчмарках InjecAgent и AgentDojo: SEAgent якобы показал 0% attack success rate (ASR) - все атаки эскалации привилегий предположительно были заблокированы, включая indirect prompt injection, RAG poisoning, untrusted agents и confused deputy. Task success rate, по неверифицированному утверждению авторов, якобы остался на уровне незащищённого агента с минимальной деградацией. False positive rate заявлен как low.

Для сравнения: IsolateGPT (Wu et al., 2024) - isolation-based подход - по некоторым публикациям демонстрирует значительное падение task success rate и повышенный false positive rate в задачах с multi-tool execution [конкретные цифры требуют верификации по первоисточнику]. SEAgent предположительно обходит это ограничение за счёт policy-based подхода: вместо того чтобы изолировать агента от данных целиком, он контролирует что именно агент может делать с этими данными. В multi-agent бенчмарках SEAgent, по заявлению авторов, дополнительно улучшает goal success rate за счёт предотвращения inter-agent interference.

Обнаружение instruction privilege escalation в агентном контексте​

Стандартные SIEM-правила не покрывают agent-specific паттерны эскалации привилегий. Нужны новые detection rules, заточенные под поведение агента, а не под network-level индикаторы.

Что мониторить:

Tool call anomalies. Агент вызывает инструмент, не соответствующий текущей задаче. Детектируется через baseline: если агент customer support дёргает HR API - аномалия. MITRE D3FEND рекомендует Access Modeling (D3-AM) для построения моделей нормального поведения.

Configuration drift. Изменения в конфигурационных файлах агентов (.mcp.json, settings.json, AGENTS.md) - индикатор cross-agent escalation. File integrity monitoring для dot-файлов в рабочей директории - минимальная мера.

Impersonation patterns. Попытки в user input или tool output заявить другую роль: «I am authorized by the CTO», «run as admin». Pattern matching на входящих данных перед передачей в контекст агента.

Transitive tool chains. Цепочки tool calls, где каждый вызов авторизован, но совокупный результат превышает intent пользователя. Детектируется через трассировку information flow graph - подход SEMemory.

Sigma-правило net_dns_external_service_interaction_domains.yml из SigmaHQ (тег T1595.002) детектирует взаимодействие с OOB-доменами (interactsh, burpcollaborator, dnslog). В SigmaHQ правило привязано к T1595.002 (Vulnerability Scanning), но в агентных системах резолвинг таких доменов чаще указывает на эксфильтрацию данных (T1567 Exfiltration Over Web Service) или подтверждение инъекции, а не на reconnaissance в классическом смысле ATT&CK.

Минимальная структура лога для detection pipeline:

{
  "agent_id": "support-agent-01",
  "user_id": "user-42",
  "user_intent": "check order status",
  "tool_called": "hr_database.query",
  "tool_params": {"table": "salaries"},
  "instruction_source": "rag_doc_1337",
  "decision": "DENY",
  "policy_matched": "no_hr_from_support"
}

Без structured logging на уровне agent-tool interaction обнаружение семантической эскалации невозможно. Audit trail обязан включать: кто инициировал (user_id), что агент решил сделать (tool + params), откуда пришла инструкция (instruction_source - system prompt, user input, RAG-документ или inter-agent message), и какое решение принял policy engine. Стандартные audit logs облачных платформ атрибутируют действия agent identity, скрывая реального инициатора - именно этот разрыв эксплуатирует privilege escalation.

Третий год я тестирую LLM-агентов на устойчивость к privilege escalation - от стартапов с одним агентом до enterprise-систем с десятками агентов в production. Наблюдение, которое повторяется без исключений: разработчики воспринимают system prompt как security boundary. Пишут «Ты не должен выполнять операции удаления» и считают проблему решённой. Это как написать # ЗАПРЕЩЕНО: rm -rf / в комментарии к bash-скрипту и ожидать, что shell его послушает.

Фундаментальная ошибка - instruction hierarchy в LLM обеспечивается тем же механизмом, что и выполнение инструкций: attention и pattern matching по тексту в контексте. Нет аппаратного ring separation, нет MMU, нет syscall boundary. Есть текст - и модель решает, какой текст важнее, на основе весов. Это probabilistic enforcement, и его можно обойти систематически, не случайно.

Подход SEAgent (если результаты подтвердятся) показывает правильное направление: детерминистический policy engine вне LLM, который проверяет каждый tool call без участия модели в принятии решения о доступе. Но даже SEAgent - research prototype; до production-ready далеко.

А пока agent frameworks продолжают давать агентам доступ ко всем зарегистрированным tools по умолчанию, MCP-серверы подключаются без верификации, inter-agent communication идёт по broadcast без проверки origin.

Мой прогноз: cross-agent privilege escalation станет основным вектором атак на agentic AI в production в ближайший год. Не потому что техника сложная - Rehberger показал, что она тривиальна. А потому что хозяйство движется к multi-agent deployment быстрее, чем к multi-agent security. Каждый новый MCP-сервер - дополнительный tool в blast radius. Каждый новый агент в пайплайне - потенциальный confused deputy. И пока vendor response на cross-agent config overwrite - «не считается достаточно серьёзным для немедленного servicing» - атакующие будут осваивать эту поверхность быстрее, чем защитники. Если хочешь пощупать эти цепочки руками - на WAPT разбирают prompt injection и tool-use exploitation в рамках модулей по AI-безопасности.