Внедрение ИИ-агентов в SOC и DevOps создаёт новый класс рисков. Угроза смещается с генерации текста на выполнение вредоносных действий: удаление ресурсов, изменение кода, обход систем защиты. Почему традиционные подходы к безопасности LLM здесь не работают и что ждёт рынок?
- 1. Введение
- 2. Смена парадигмы: от защиты данных к контролю действий
- 3. Почему старая модель угроз больше не работает?
- 4. Архитектура угроз: 3 цели атакующего в свете OWASP Top 10
- 5. Стратегия защиты: инженерный контроль над активным субъектом
- 5.1. Zero Trust для нечеловеческих идентичностей
- 5.2. Least Privilege и принцип минимальной автономии
- 5.3. Прокси-слой и ограждающие механизмы (guardrails)
- 5.4. Контроль экосистемы и предварительная проверка компонентов
- 5.5. Наблюдаемость и интеграция в AISecOps
- 5.6. Изоляция и песочницы
- 5.7. Адаптация моделей угроз и регуляторный контекст
- 6. Российский рынок AI Security в 2026: тренды и AISecOps-платформы
- 7. Выводы
Введение
Вопрос безопасности ИИ-агентов перешёл из теоретической плоскости в критически важную операционную задачу для организаций, внедряющих автономные системы в продуктивные контуры с реальными полномочиями. Если раньше ИИ в основном генерировал текст и анализировал данные, то теперь агенты стали активными исполнителями, напрямую влияющими на состояние инфраструктуры.
Фактически формируется новый, особо рискованный класс нечеловеческих идентичностей (Non-Human Identity). В отличие от статических сервисных аккаунтов, эти системы обладают недетерминированным поведением на основе языковых моделей и доступом к инструментарию. Они работают автономно, круглосуточно и оперируют широкими правами, делегированными им для выполнения задач.
О масштабах их внедрения косвенно свидетельствуют и данные об инцидентах: до 25 % компаний фиксировали утечки данных с участием агентов, а около 80 % — попытки несанкционированного доступа, связанные с их использованием.
Поведение автономного агента сложно оценивать традиционными методами. Внешне корректные операции могут скрывать вредоносную логику, а последствия ошибок или атак выходят за рамки привычных сценариев работы с языковыми моделями.
Возникает вопрос: как обеспечить архитектурный контроль над субъектом, чьи действия на уровне журналов и API выглядят допустимыми, но фактически приводят к нарушению безопасности? Ответ требует понимания новых тактик атакующих и пересмотра подходов к защите.
Смена парадигмы: от защиты данных к контролю действий
Внедрение ИИ-агентов в центры мониторинга безопасности (Security Operations Center, SOC) и процессы разработки и эксплуатации (Development and Operations, DevOps) стало реакцией на ограничения существующих инструментов.
Традиционные подходы в SOC не справляются с объёмом телеметрии и скоростью атак.
По оценкам, около 40 % центров мониторинга используют элементы автоматизации, однако ключевые этапы анализа и реагирования по-прежнему выполняются вручную. Даже при наличии систем управления событиями безопасности (Security Information and Event Management, SIEM) и платформ оркестрации и реагирования (Security Orchestration, Automation and Response, SOAR) значительная часть процессов остаётся полуавтоматической.
Аналитики вынуждены обрабатывать постоянно растущий поток событий от сетевых сенсоров, облачных платформ и агентов на рабочих станциях. Это приводит к задержкам в расследовании инцидентов, а часть атак теряется в общем потоке событий.
Автономные ИИ-помощники частично снимают эту нагрузку, переводя рутинные операции в автономный режим. В практических сценариях они уже сейчас:
- выполняют первичную классификацию событий, снижая долю ложных срабатываний;
- коррелируют телеметрию из разрозненных источников с учётом контекста инфраструктуры;
- инициируют стандартные ответные действия: от обогащения индикаторов компрометации (Indicators of Compromise, IoC) до изоляции узлов и обновления правил реагирования.
В DevOps переход к агентской модели происходит ещё быстрее. Автоматизация изначально заложена в жизненный цикл разработки ПО (Software Development Life Cycle, SDLC), поэтому автономные системы органично встраиваются в конвейеры непрерывной интеграции и развёртывания (Continuous Integration/Continuous Deployment, CI/CD). Если раньше ИИ помогал разработчикам генерировать код или находить ошибки, сегодня агенты управляют этапами сборки, тестирования и развёртывания ПО.
Так формируется переход от классического DevSecOps к AgentSecOps, где автономные агенты становятся неотъемлемой частью жизненного цикла безопасности.
Почему старая модель угроз больше не работает?
В эпоху больших языковых моделей (Large Language Model, LLM) основные риски были сосредоточены вокруг данных: утечек через диалог, отравления обучающих выборок или генерации нежелательного контента. Соответственно, защита строилась вокруг контроля запросов и фильтрации ответов.
С появлением автономных исполнителей эта модель устарела. Агент — это не интерфейс для взаимодействия, а субъект с делегированными полномочиями. Он действует от имени служебной учётной записи и обладает правами доступа к API, облачным ресурсам, репозиториям кода и конвейерам CI/CD. Его задача — не сформировать ответ, а изменить состояние систем.
Соответственно, меняется и цель атакующих. Основной вектор смещается с получения вредоносного ответа на перехват управления агентом (Goal Hijacking). По данным отрасли, более 60 % атак на автономные системы направлены на извлечение или подмену внутренних инструкций. Получив контроль над логикой принятия решений, злоумышленник использует легитимные права системы для дальнейшей эскалации.
В SOC-контуре скомпрометированный агент может не «сливать» данные напрямую, а искажать или удалять события из логов, скрывая реальную атаку. Например, он может получить скрытую инструкцию стереть все упоминания определённого IP-адреса за последние сутки, сделав атаку «невидимой».
В DevOps-среде компрометация приводит не к утечке кода, а к нарушению целостности артефактов сборки и программных компонентов, что затрагивает всю цепочку поставок. Например, через уязвимый сервер контекста модели (Model Context Protocol, MCP) в процесс сборки может быть внедрена зависимость со скрытым механизмом удалённого управления. Агент, считая источник доверенным, использует скомпрометированный компонент, в результате чего происходит заражение всей цепочки поставок.
Меняется и масштаб последствий. Если ранее инциденты ограничивались локальными утечками или репутационными потерями, то в агентской модели они создают прямые операционные риски: остановку сервисов, компрометацию цепочек поставок и нарушение процессов реагирования. Безопасность теперь должна отвечать не на вопрос «что агент сказал», а на вопрос «что он сделал, имел ли на это право и в каком контексте».
Рисунок 1. Эталонная архитектура автономного ИИ-агента и ключевые точки возникновения рисков безопасности
Архитектура угроз: 3 цели атакующего в свете OWASP Top 10
Публикация OWASP Top 10 for Agentic Applications 2026 зафиксировала важный сдвиг в восприятии рисков автономных ИИ-систем. В центре анализа оказался не отдельный алгоритм и не качество ответов модели, а агент как активный исполнитель, обладающий автономией и доверенными правами доступа к инфраструктуре.
Это привело к изменению логики классификации угроз. OWASP описывает не абстрактные «ошибки ИИ», а конкретные классы атак, направленные на изменение поведения, полномочий и устойчивости автономных систем. Несмотря на различия сценариев, все риски укладываются в 3 стратегические цели атакующего.
Цель 1: Перехват управления
Перехват управления агентом (Goal Hijacking, ASI01) — это эволюция классических атак на инъекцию промптов (Prompt Injection) для автономных сценариев. Вредоносные инструкции теперь внедряются не в прямой пользовательский запрос, а в контекст выполнения задачи, который агент считает доверенным.
Современные атаки используют косвенную инъекцию (Indirect Prompt Injection). Вредоносные инструкции маскируются под легитимные данные в источниках, с которыми агент работает при выполнении задачи. Это могут быть документы в системах извлечения сгенерированных ответов (Retrieval-Augmented Generation, RAG-хранилищах), обращения в системе поддержки, комментарии в коде, электронные письма или отчёты.
Обрабатывая такие данные как рабочий контекст, агент изменяет цель или последовательность действий, не фиксируя это как аномалию.
Показательный пример — инцидент EchoLeak (CVE-2025-32711), при котором специально сформированное письмо привело к несанкционированной передаче данных через Microsoft 365 Copilot. Уязвимость была связана не с ошибкой модели, а с тем, что агент интерпретировал содержимое письма как допустимую инструкцию в рамках задачи.
Обнаружение таких атак осложняется маскировкой инструкций под структурированные форматы (JSON, YAML, конфигурационные файлы), которые часто не проходят дополнительную семантическую проверку.
Защита в этом случае строится вокруг жёсткой фиксации цели выполнения задачи и проверки её неизменности на протяжении всего жизненного цикла. Дополняющим механизмом выступают семантические ограничители (guardrails) — модели, которые анализируют отклонение поведения агента от исходной миссии, независимо от источника контекста.
Цель 2: Злоупотребление доверенными правами
Вторая цель атакующего — использование легитимных прав агента против самой системы. В классификации OWASP это риски неправильного использования инструментов (Tool Misuse, ASI02) и злоупотребления идентификацией и привилегиями (Identity & Privilege Abuse, ASI03).
Агент по своей природе работает с привилегированными интерфейсами: API облачных платформ, CLI-утилитами, почтовыми сервисами, репозиториями кода и CI/CD-конвейерами. Атакующему не нужно обходить механизмы аутентификации — достаточно вынудить агента применить свои права в деструктивном сценарии.
Например, в инциденте с Amazon Q вредоносная инструкция была внедрена не напрямую в диалог с агентом, а в запрос на слияние кода (pull request), который тот анализировал как часть своей рабочей задачи. Инструкция выглядела как обычный технический комментарий и не вызывала подозрений при поверхностной проверке.
В результате агент интерпретировал этот текст как допустимое указание к действию и попытался выполнить операции по удалению облачных ресурсов с помощью интерфейса командной строки Amazon Web Services (Amazon Web Services Command Line Interface, AWS CLI). Он не обходил механизмы аутентификации и не эксплуатировал уязвимости в инфраструктуре.
Важно корректно разграничивать риски внутри цепочки поставок (Agentic Supply Chain Vulnerabilities, ASI04), связанные с компрометацией внешних компонентов, которые агент использует как доверенные: MCP-серверы, плагины, сторонние инструменты, модели и наборы данных. Компрометация такого компонента автоматически расширяет поверхность атаки.
Пример — обнаруженный вредоносный MCP-сервер, который выдавал себя за почтовый инструмент Postmark. Он скрытно перенаправлял копии обрабатываемых сообщений, превращаясь в канал утечки данных. Агент продолжал использовать компонент как легитимный, не имея возможности обнаружить подмену.
Ключевые меры защиты включают минимизацию и временное предоставление прав (Just-in-Time Access), а также ведение реестра компонентов ИИ (AI Bill of Materials, AIBOM). Без AIBOM невозможно оперативно выявлять уязвимые зависимости и оценивать масштаб компрометации цепочки поставок.
Цель 3: Подрыв устойчивости агентной системы
Третья стратегическая цель — не прямой контроль, а дестабилизация всей системы. В OWASP это отравление памяти и контекста (Memory & Context Poisoning, ASI06), небезопасные межагентские коммуникации (Insecure Inter-Agent Communication, ASI07) и каскадные сбои (Cascading Failures, ASI08).
Отравление памяти отличается от разовой инъекции долговременным эффектом. Вредоносные инструкции или данные внедряются в состояние агента, историю взаимодействий или базы знаний (RAG), используемые при последующих решениях. Например, изменение данных в RAG-хранилище может привести к устойчивому игнорированию определённых индикаторов компрометации, формируя постоянную «слепую зону».
В многоагенских системах последствия усиливаются. Компрометация памяти агента-планировщика способна распространять искажённые инструкции на подчинённые агенты. При отсутствии проверки подлинности и целостности межагенских сообщений (ASI07) это приводит к каскадному отказу (ASI08), когда некорректные действия одного компонента лавинообразно нарушают работу всей системы. Этот сценарий известен как Multi-Agent Escalation.
Отдельно стоит риск эксплуатации доверия человека (Human-Agent Trust Exploitation, ASI09), когда агент, будучи скомпрометированным, использует свою убедительность для манипуляции пользователем, заставляя того санкционировать вредоносное действие, делая атаку неотслеживаемой.
Защита требует отдельного контура безопасности для памяти и коммуникаций: контроль целостности данных, аудит состояний, взаимная аутентификация агентов. Необходимы механизмы автоматической изоляции и «аварийного отключения» (kill-switch) для сдерживания каскадных сбоев, а также чёткие процедуры подтверждения высокорисковых действий человеком.
Рисунок 2. Карта угроз OWASP Top 10 for Agentic Applications 2026 для ИИ-агентов
Стратегия защиты: инженерный контроль над активным субъектом
Защита автономных ИИ-исполнителей требует смещения фокуса с контроля данных на контроль действий. Агент — это не источник информации, а активный участник инфраструктуры, разновидность нечеловеческой идентичности (Non-Human Identity), действующей от имени системы. Его безопасность должна выстраиваться по тем же инженерным принципам, что и защита сервисных учётных записей, автоматизированных конвейеров и оркестраторов.
Zero Trust для нечеловеческих идентичностей
Базовый принцип — распространение модели нулевого доверия (Zero Trust). Каждый агент рассматривается как потенциально скомпрометированный независимо от его назначения и происхождения. Это исключает неявное доверие внутри инфраструктуры и требует явной проверки каждого обращения к инструментам, API и инфраструктурным ресурсам.
На практике это выражается в строгом разделении зон доступа. Агенту разрешается взаимодействовать только с заранее определёнными сервисами и конечными точками. Даже в пределах одного SOC или CI/CD-конвейера отсутствует «плоский» контур доверия: каждый инструмент и сервис обрабатывается как отдельный объект с собственными правилами доступа.
Least Privilege и принцип минимальной автономии
Принцип наименьших полномочий (Least Privilege) в агентских системах дополняется ограничением автономии. Агенту предоставляется ровно тот объём самостоятельности, который необходим для выполнения конкретной задачи.
Например, система может анализировать результаты статического и динамического тестирования безопасности или обогащать события контекстом, но не принимать финальное решение о развёртывании без дополнительного подтверждения. Аналогично, она может инициировать изоляцию узла, но не изменять политики доступа или сетевые правила.
Для выполнения привилегированных операций используются временные и строго ограниченные учётные данные (Just-in-Time Access). Каждое действие сопровождается проверкой контекста и цели, что снижает риск злоупотребления легитимными правами.
Прокси-слой и ограждающие механизмы (guardrails)
Между агентом и используемыми инструментами размещается прокси-слой, который анализирует запросы, промежуточные планы действий и последовательность вызовов API.
Guardrails — это набор правил и механизмов контроля, ограничивающих поведение агента. Они проверяют, соответствует ли цепочка действий исходной задаче, выявляют логические отклонения и предотвращают применение инструментов вне допустимого контекста. Таким образом, даже формально разрешённые операции не могут быть выполнены, если они противоречат целям задачи или политике безопасности.
Контроль экосистемы и предварительная проверка компонентов
Все внешние компоненты, с которыми взаимодействует агент — MCP-серверы, плагины, сторонние инструменты и модели — подключаются только после предварительной проверки.
Формируется контролируемый контур поставки компонентов ИИ, аналогичный процессам управления зависимостями в DevSecOps. Для каждого компонента фиксируются источник, версия и целостность, что снижает риски компрометации цепочки поставок.
Наблюдаемость и интеграция в AISecOps
Классические метрики безопасности недостаточны для агентских систем. Помимо событий доступа и сетевой активности требуется сбор поведенческих данных: последовательности вызовов инструментов, изменения паттернов действий и отклонения поведения от ожидаемого сценария.
Эти данные интегрируются в SIEM и SOAR как отдельный класс событий. На их основе формируется модель AISecOps, в которой контроль ИИ-агентов становится частью повседневного мониторинга и реагирования.
Изоляция и песочницы
Даже при наличии превентивных мер агенты должны выполняться в изолированной среде. Контейнеры или виртуальные машины с жёсткими ограничениями на доступ к сети, файловой системе и системным ресурсам позволяют локализовать последствия ошибок или атак. Изоляция служит последним уровнем защиты, предотвращающим распространение инцидента за пределы агентского контура.
Адаптация моделей угроз и регуляторный контекст
Защита агентских систем невозможна без формализации угроз. Таксономии OWASP Top 10 for Agentic Applications и MITRE ATLAS могут использоваться как основа для моделирования рисков, но требуют адаптации под конкретную инфраструктуру и регуляторные требования.
В российском контексте это означает учёт нормативов ФСТЭК, отраслевых стандартов и особенностей отечественного технологического стека при построении архитектуры защиты ИИ-агентов.
Рисунок 3. Архитектура системы безопасности автономных ИИ-агентов в облаке
Российский рынок AI Security в 2026: тренды и AISecOps-платформы
Внедрение ИИ-агентов в критически важные бизнес-процессы формирует в России новый сегмент рынка — AI Security. Это направление объединяет защиту, наблюдение и управление автономными ИИ-системами (AISecOps). Основными факторами роста являются:
- Курс на импортозамещение, который требует отказа от зарубежных средств защиты ИИ и внедрения отечественных решений, совместимых с российским технологическим стеком.
- Повышенное внимание регуляторов к рискам, связанным с автономными системами принятия решений.
- Операционная необходимость — традиционные средства ИБ не обеспечивают контроль над агентами, действующими от имени сервисных учётных записей и обладающими широкими полномочиями.
Рынок защиты ИИ в России в 2026 году оценивается минимум в 1 млрд рублей, а к 2029 году прогнозируется рост до 11 млрд рублей. Этот рост обеспечивается внедрением ИИ-агентов в продуктивные среды, прежде всего в финансовом секторе, промышленности, телеком-отрасли и крупном корпоративном ИТ.
Существующие подходы на рынке
Сейчас на рынке прослеживаются 2 подхода к развитию AI Security.
Расширение классических решений безопасности
Крупные российские компании, такие как ГК «Солар», BI.ZONE и Avanpost, адаптируют свои решения для управления привилегированным доступом (PAM), распространяя их контроль на ИИ-агентов как на новый класс нечеловеческих идентичностей.
Решения позволяют:
- управлять жизненным циклом учётных данных агентов (JWT-токены, сертификаты, API-ключи), выдавая их по требованию (Just-in-Time Access) и с минимальными привилегиями;
- применять принцип нулевого доверия (Zero Trust): изолировать сессии агентов и реализовывать процедуры обязательного утверждения (например, по механизму «четыре глаза») для выполнения критичных операций;
- вести детализированный аудит всех операций и назначать ответственного куратора для санкционирования заранее определённых рискованных действий агента.
Специализированные решения для безопасности ИИ
Появляются платформы, созданные специально для защиты ИИ-агентов. Пример — AppSec.GenAI от компании AppSec Solutions. Платформа предназначена для тестирования устойчивости ИИ-моделей и агентов к различным угрозам. Функциональные возможности включают:
- автоматизированное тестирование на уязвимости: от классических Prompt Injection и Jailbreaking до Goal Hijacking и утечек данных через косвенные инъекции;
- использование эталонных таксономий угроз (OWASP Top 10 for LLM, MITRE ATLAS) для систематизации проверок;
- интеграцию в CI/CD-конвейеры как security gate: при обнаружении критических уязвимостей платформа может блокировать релиз модели или агента.
Этот подход даёт более глубокую, специализированную экспертизу, но требует от компаний внедрения и освоения нового инструментария.
Перспективные направления
По мере усложнения угроз будут формироваться новые рыночные ниши, наиболее актуальные для российской действительности.
Защитные прокси для ИИ, или «ограждающие механизмы» (AI Guardrails), чтобы контролировать действия агентов в реальном времени. Они должны быть совместимы с российскими облачными платформами (VK Cloud, SberCloud, Yandex Cloud) и моделями (GigaChat, YandexGPT), учитывая русский язык и особенности локальных бизнес-процессов.
Платформы аудита ИИ-цепочек поставок для создания единого реестра всех компонентов ИИ (AI Bill of Materials, AIBOM) — моделей, плагинов, MCP‑серверов и инструментов. Они проверяют эти компоненты на уязвимости и признаки компрометации, включая неожиданные внешние вызовы, а также контролируют легитимность и цифровые подписи сторонних плагинов и моделей перед их использованием в продуктивной среде.
Выводы
К концу 2026 года рынок AI Security в России, по оценкам, вырастет в 4–5 раз. Основной тренд — переход от отдельных решений к полнофункциональным AISecOps-платформам, которые объединяют guardrails, наблюдаемость, аудит цепочек поставок и автоматизированное реагирование с интеграцией в SIEM и SOAR.
Импортозамещение в этом сегменте выступает не ограничением, а фактором развития: отсутствие готовых западных решений стимулирует создание отечественных продуктов, изначально адаптированных к российскому стеку и требованиям регуляторов. В результате российский рынок AI Security формирует собственную экосистему, ориентированную на защиту автономных ИИ-агентов в условиях технологического суверенитета и усложняющихся киберугроз.
