В 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 и её архитектурная хрупкость
В теории иерархия инструкций 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 через файловую систему.
- Indirect prompt injection в данных репозитория (комментарий в коде, markdown-файл) захватывает Copilot.
- Copilot создаёт или модифицирует
.mcp.json- конфигурацию MCP-серверов Claude Code - добавляя вредоносный сервер с arbitrary code execution. - Copilot записывает
CLAUDE.mdс instructions для Claude Code, направляющими на выполнение определённых действий. - Разработчик переключается на Claude Code. Claude подхватывает изменённую конфигурацию и выполняет произвольный код через подключённый MCP-сервер.
- Claude обновляет
.vscode/settings.jsonCopilot - петля замыкается.
Предусловия и ограничения:
- Разработчик использует несколько coding-агентов на одной кодовой базе. Сценарий распространён: Copilot + Claude Code, Copilot + Gemini и другие комбинации для «second opinion» или code review.
- Агент-инициатор должен иметь возможность записи в dot-файлы без approval. После disclosure некоторые вендоры добавили подтверждения для перезаписи собственных конфигураций - но не конфигураций других агентов.
- Для API-based агентов без файловой системы прямой вектор не применим. Аналогичная логика работает через shared memory stores, shared databases или любой другой persistent medium, к которому имеют доступ несколько агентов.
Защита: Mandatory Access Control для агентных систем
SEAgent: ABAC-политики и Decision Engine
SEAgent переносит принципы Mandatory Access Control (MAC) из мира ОС (SELinux, AppArmor) в агентные LLM-системы. Подход строится на Attribute-Based Access Control (ABAC): каждая сущность маркируется статическими атрибутами, а политики определяют допустимые пути выполнения.Архитектура из четырёх компонентов:
Концептуально политика для предотвращения confused deputy в MAS:
Код:
DENY tool_call
WHERE subject.source = "inter-agent"
AND object.sensitivity >= "high"
AND NOT verified(subject.original_user_intent)Результаты: количественная оценка
По заявленным, но независимо не верифицированным результатам оценки на бенчмарках 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:
JSON:
{
"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"
}Третий год я тестирую 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-безопасности.
