Безопасность AI агентов: атаки и детект в enterprise

В кейсе AML.CS0039 из MITRE ATLAS исследователи собрали полную цепочку компрометации enterprise-системы - и для этого не понадобился ни один эксплойт. Создали тикет в публичном Jira Service Management, вложили prompt injection payload в текст заявки и получили данные всех тикетов инстанса через штатный вызов Atlassian MCP-инструмента. Ни обхода WAF, ни CVE. Инженер поддержки подключил Claude Sonnet через MCP-интеграцию, агент обработал вредоносную инструкцию как часть задачи и вернул результат атакующему легитимным API-вызовом. Unit 42 воспроизвели аналогичную схему на multi-agent пайплайне из CrewAI и AutoGen: news-агент с web content reader делал SSRF к внутренним IP - и атака работала идентично на обоих фреймворках. Это не баг реализации - это системное свойство архитектуры. Ниже - разбор поверхности атаки, таксономия техник с маппингом на MITRE ATT&CK, воспроизводимые шаги и подходы к детектированию того, что классический SIEM не увидит.

Поверхность атаки AI-агента: почему агент - не чат-бот​

Разница между LLM-чатботом и AI-агентом - не в "продвинутости" модели. Чатбот генерирует текст. Агент вызывает tool calls и меняет состояние внешних систем: создаёт тикеты, отправляет письма, выполняет SQL-запросы, деплоит код. Это фундаментально другая модель угроз, и безопасность AI агентов требует отдельного подхода. Подробнее - в нашем статье о безопасность llm приложений.

Collapsed instruction boundary. В агентных системах инструкции и данные идут по одному каналу в формате natural language. Агент архитектурно не различает доверенную команду оператора и вредоносный payload, вложенный в обрабатываемый документ - email, PDF, metadata тикета, веб-страницу. Каждый документ, который агент читает, - потенциальный вектор инъекции. OWASP LLM Top 10 классифицирует это как Prompt Injection (LLM01:2025): crafted input меняет поведение LLM, обходя safety controls или вытаскивая конфиденциальные данные.

Toxic combinations. Изолированно безопасные разрешения создают опасные пути через агента. Read-доступ к email, write-доступ к Slack, search-доступ к SharePoint - каждое разрешение безобидно по отдельности. Но агент, держащий все три одновременно, создаёт adjacency между системами, которые никогда не проектировались для взаимного доверия. Christian Schneider описывает этот паттерн как "toxic combinations" - класс AI agent уязвимостей, уникальный для агентных архитектур. По отдельности - ничего страшного. Вместе - готовый путь к эксфильтрации.

Excessive Agency. OWASP выделяет Excessive Agency (LLM06:2025) отдельным риском: LLM с избыточными разрешениями или автономией выполняет непредусмотренные действия. На практике - агент для HR-автоматизации оказывается с доступом к финансовым API, потому что ему выдали service account с broad IAM role при деплое и никогда не пересмотрели scope. Знакомо?

По данным Check Point 2026 Cybersecurity Report, анализ 10 000 MCP-серверов выявил security weaknesses в 40% из них. Четыре из десяти. Это не уязвимости модели - это инфраструктурные дыры в слое, через который агенты вызывают инструменты и через который проходят все риски автономных AI агентов.

Полная цепочка: от тикета Jira до эксфильтрации через MCP​

Шаг 3 - Триггер. Инженер поддержки использует Claude Sonnet через MCP-интеграцию для помощи в обработке заявки. Агент читает содержимое тикета - вредоносный prompt обрабатывается как часть рабочей задачи. Человек даже не подозревает о происходящем.

Шаг 4 - Privilege escalation через tool invocation. Информация, запрошенная вредоносным промптом, доступна агенту через Atlassian MCP-инструменты. Агент вызывает MCP tool, который читает и собирает тикеты Jira - инструменты дают расширенные привилегии на JSM-инстансе жертвы.

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

Ключевое наблюдение: ни один шаг не генерирует алерт в классическом SIEM. Агент использовал авторизованные инструменты, обращался к данным в рамках своих разрешений, формировал ответ через штатный API. Prompt injection атаки этого класса невидимы для threshold-based мониторинга. SIEM молчит, потому что с его точки зрения ничего аномального не произошло.

Таксономия атак с маппингом на MITRE ATT&CK​

Русскоязычные материалы по LLM security в enterprise обычно ограничиваются описанием prompt injection как единственного вектора. В реальности атакующий эксплуатирует цепочку техник, которая маппится на существующую таксономию ATT&CK. MITRE ATLAS дополняет классический фреймворк техниками для AI-систем, а OWASP Top 10 for Agentic Applications 2026 формализует threat-класс с отдельными категориями для tool misuse, goal hijacking и identity abuse.

Credential Access и Initial Access​

Агент - это identity с credentials. Компрометация агента даёт не shell, а набор авторизованных API-вызовов.

Cloud Accounts (T1078.004). Агент работает через cloud-аккаунт - IAM role, service account, managed identity. Компрометация агента = компрометация этого аккаунта со всеми привязанными разрешениями. IBM X-Force фиксирует рост credential-based атак на 71% год к году (2024), а в dark web ежедневно появляется более 6000 свежих учётных записей.

Cloud Instance Metadata API (T1552.005). Агент с доступом к compute-инстансу может обратиться к metadata endpoint (169.254.169.254) и вытянуть временные credentials привязанного service account. Если агент обрабатывает внешний контент без sandboxing, prompt injection может инициировать этот запрос. Для контролируемых сред - классическая IMDSv2-митигация, но агент, вызывающий произвольные URL через web reader tool, обходит этот контроль по дизайну. Тут IMDSv2 не спасает.

Steal Application Access Token (T1528). Агент хранит или получает OAuth-токены, API-ключи, JWT для вызова внешних сервисов. Утечка контекста через prompt injection или memory poisoning приводит к эксфильтрации этих токенов. В multi-agent архитектурах token-based транзакции между агентами могут наследовать разрешения с минимальным logging context.

Lateral Movement и confused deputy​

Application Access Token (T1550.001). Украденный или делегированный токен агента используется для перемещения между системами. В multi-agent архитектуре manager-agent может передать worker-agent полный набор прав, а worker - выполнить действие без проверки исходного намерения пользователя.

Unit 42 показали это на multi-agent investment advisory приложении: news-агент с web content reader tool выполнял SSRF к внутренним IP-адресам по запросу атакующего. Оркестрационный агент делегировал задачу, news-агент вызвал инструмент - атака прошла штатным путём через легитимные вызовы. Критически важно: атака работала идентично на CrewAI и AutoGen. Это не framework-specific баг, а confused deputy problem в агентной форме.

Claude Mythos, по данным Zero Networks, продемонстрировал автономный захват симулированной сети в 3 из 10 попыток - первая модель, которая достигла этого результата, используя только легитимные пути доступа. Artificial Intelligence (T1588.007, Resource Development) как техника ATT&CK фиксирует именно такое применение: AI-модели используются для разработки эксплойтов и автоматизации атак. Три из десяти - и это без специальной заточки под offensive.

Collection и Impact​

Code Repositories (T1213.003). Агент с доступом к Git-репозиториям через MCP-интеграцию или API собирает исходный код, конфигурации, secrets. Типичный сценарий для DevOps-агентов с широким scope.

Financial Theft (T1657). Агент с доступом к платёжным API или ERP-системе инициирует финансовые транзакции. По данным Kaspersky, OpenClaw использовался для автоматизации торговли - агент не давал советы, а совершал сделки.

Tool poisoning и AI supply chain security​

Отдельный класс атак - подмена описания инструмента. Агент выбирает tool по объявленным capabilities (description, schema, metadata MCP-сервера). Если атакующий контролирует MCP-сервер или подменяет метаданные инструмента, агент может:

• отправить данные на endpoint атакующего вместо легитимного сервиса
• выполнить действие с побочными эффектами под видом безобидной операции
• передать credentials инструменту, который их exfiltrate

Вариант rug pull опаснее: инструмент выглядит легитимным при human-in-the-loop review, а вредоносным становится позже - после обновления серверной стороны. Прямой аналог классической supply chain атаки, только жертва - не разработчик, а агент. OWASP Top 10 for AI Agents (2026) выделяет Supply Chain Attacks (ASC-09) и Knowledge Base Poisoning (AKP-10) отдельными категориями рисков.

Data and Model Poisoning (LLM04:2025 по OWASP LLM Top 10) в контексте AI supply chain security проявляется через RAG poisoning и memory poisoning: вредоносная инструкция, попавшая в долговременную память или embedding store, влияет на поведение агента в будущих сессиях без повторного взаимодействия атакующего. Один раз отравил - работает само. Агентная система зависит от стека: модель, датасеты для fine-tuning, MCP-серверы, open-source библиотеки, Docker-образы, plugins - каждый компонент требует верификации как часть аудита безопасности LLM и агентного пайплайна.

Детектирование: что видит и не видит классический стек​

Угрозы искусственного интеллекта в enterprise создают слепую зону для традиционного мониторинга. Endpoint detection видит процессы и сетевой трафик - но агент действует через авторизованные API-вызовы, не порождая подозрительных процессов. Network monitoring видит соединения - но tool call к MCP-серверу выглядит как легитимный HTTPS-запрос. Классический стек тут слеп. Нужен другой подход.

Runtime-детекторы: что уже реализовано​

Google Agent Platform Threat Detection (часть Security Command Center) - одна из первых production-реализаций runtime-мониторинга для AI-агентов. Архитектура: watcher process собирает события во время работы агента, данные анализируются в памяти и не персистируются, если инцидент не выявлен. Для скриптов используется NLP-анализ Bash и Python на предмет вредоносного кода.

Набор runtime-детекторов покрывает характерные для агентных атак паттерны:

• AGENT_ENGINE_ADDED_MALICIOUS_BINARY_EXECUTED - выполнение бинарника, идентифицированного threat intelligence как вредоносный, не входящего в оригинальный workload агента
• AGENT_ENGINE_ADDED_MALICIOUS_SKILL_EXECUTED - запуск вредоносного skill, не входящего в исходный набор агента
• AGENT_ENGINE_BASE64_ENCODED_PYTHON_SCRIPT_EXECUTED - запуск base64-закодированного Python-скрипта (Defense Evasion)
• AGENT_ENGINE_FIND_GCP_CREDENTIALS - поиск cloud private keys и credentials в среде контейнера (Credential Access)
• AGENT_ENGINE_SEARCH_PRIVATE_KEYS_OR_PASSWORDS - поиск приватных ключей и паролей в среде выполнения
• AGENT_ENGINE_STEGANOGRAPHY_TOOL_DETECTED - обнаружение стеганографических инструментов (C2 через скрытые каналы)

Control-plane детекторы анализируют аудит-логи (IAM, BigQuery, Cloud SQL) и stdout/stderr агента на предмет data exfiltration attempts, excessive permission denials (паттерн privilege escalation) и suspicious token generation.

Ключевое ограничение: всё это покрывает атаки на среду выполнения агента (container escape, malicious binary), но не покрывает tool invocation abuse - когда агент вызывает легитимный инструмент с вредоносным intent. Для защиты AI агентов от атак уровня AML.CS0039 нужен мониторинг на уровне identity и tool calls. А его почти ни у кого нет.

Identity-layer мониторинг и аудит tool calls​

Защита AI агентов требует смещения фокуса с endpoint monitoring на identity layer.

Inventory agent identities. Каждый agent instance - уникальный идентификатор, привязанный к криптографическому материалу. Без полной инвентаризации (какие агенты существуют, какие credentials несут, какие IAM roles используют) остальные контроли бесполезны. По данным Permiso, stale agent credentials - эксплуатируемый gap вне зависимости от активности оригинального use case.

Per-agent behavioral baselines. Не threshold-based алертинг, а baselines на основе наблюдаемой активности каждого конкретного агента. Девиация - неожиданные API calls, нехарактерные паттерны доступа к данным, активность за пределами рабочих часов - security-сигнал для red teaming и пентеста LLM приложений.

Tool call audit logging. Каждый tool call агента должен логироваться с полным контекстом. Минимальный набор полей для интеграции в SIEM:
Корреляция tool calls с IAM-событиями выявляет паттерны, невидимые при изолированном анализе: серия read-вызовов к разным проектам Jira за короткий промежуток, инициированная одним агентом в одной сессии, - характерный индикатор data exfiltration после prompt injection. Без структурированного логирования tool calls с request ID восстановить цепочку событий при инциденте не получится.

Threat model для агентного пайплайна - чек-лист​

Прежде чем деплоить агента в production, threat model по принципам NIST AI RMF (MAP -> MEASURE -> MANAGE) покрывает agent-специфичные риски. Дизайн-тест из Zero Trust framework Anthropic: контроль делает атаку невозможной или просто неудобной? Rate limiting и нестандартные порты - это неудобство. Deny-by-default, отсутствующий network path и short-lived credentials - это невозможность. Разница принципиальная.

MAP - определение контекста:

• Полный перечень доступных tool calls (не "примерный набор", а exhaustive list)
• Какие данные агент может читать, какие - модифицировать
• Через какие каналы агент получает ввод (пользовательский ввод, email, RAG, webhook)
• Какие из каналов содержат недоверенный контент

MEASURE - оценка рисков:

• Для каждой пары (tool call + data source) - blast radius при компрометации
• Есть ли toxic combinations: пары разрешений, безопасные по отдельности, опасные вместе
• Отделён ли user input от system prompt архитектурно (не через prompt-инструкции, а через разные каналы ввода)
• Может ли агент получить доступ к credentials других сервисов через metadata API или environment variables

MANAGE - митигация:

• Deny-by-default: каждый tool call требует явного разрешения
• Sandboxing: агент, читающий внешний контент, работает в контейнере/microVM с ограниченными сетевыми доступами
• Short-lived credentials: токены с TTL в минутах, автоматический rotation (статические API-ключи в .env или Docker-образе стоит считать скомпрометированными)
• Human-in-the-loop для destructive actions: удаление данных, отправка email, финансовые операции
• Логирование всех tool calls с session ID и request ID

Пример минимальной политики разрешений для HR-агента:
Безопасность искусственного интеллекта в бизнесе начинается не с guardrails на уровне промпта, а с архитектуры: identity management, scope разрешений, sandboxing среды выполнения, мониторинг tool calls. Эти контроли - не новые изобретения; это адаптация Zero Trust и least privilege к новому классу non-human identities.

Главная проблема безопасности AI агентов - не prompt injection. Prompt injection - вектор доставки, аналог фишингового письма. Реальная проблема - identity sprawl для non-human identities. Каждый агент получает service account, API-ключи, OAuth-токены. В подавляющем большинстве случаев эти credentials выдаются при деплое один раз и никогда не пересматриваются. Агент деприкейтится - credentials остаются. Добавляется новый MCP-сервер - ему наследуются разрешения предыдущего.

Я строил threat models для агентных пайплайнов на LangChain и CrewAI в нескольких enterprise-контурах - и каждый раз главное открытие было одинаковым. Не изощрённый adversarial suffix, не model poisoning, не zero-day в фреймворке. Банальный stale service account с broad IAM role, выданный полтора года назад для "быстрого прототипа" и забытый. Весь OWASP LLM Top 10 сфокусирован на модели, а 75% реальных вторжений в 2024 году - на учётных данных. Для агентных систем этот перекос ещё критичнее, потому что агент по определению действует автономно и его credentials работают без участия человека. Фреймворки меняются каждые полгода, а IAM-гигиена не менялась десятилетиями. Если вы закрываете prompt injection guardrails, но не инвентаризируете agent credentials и не ротируете токены - вы ставите бронированную дверь в стену из гипсокартона. На HackerLab (https://hackerlab.pro) есть лаба, где цепочку prompt injection -> tool invocation -> privilege escalation можно собрать end-to-end без подсказок.