Атакующие всё реже бьют напрямую по ИИ-агентам — они идут к ним через знакомую инфраструктуру: непропатченные серверы, криво настроенный Active Directory, избыточные права в облаке. Каждое развёртывание ИИ-агента увеличивает поверхность атаки, потому что агент наследует разрешения и зависимости от систем, спроектированных задолго до появления LLM.
Цифры, от которых становится не по себе
71% организаций хотя бы пилотно внедряют ИИ-агентов в корпоративные приложения. 31% уже перевели их в продакшен. 70% выдают агентам больше привилегий, чем живому сотруднику на аналогичной должности — это данные Infosecurity Magazine. Итог закономерен: 76% компаний с избыточными правами ИИ фиксируют инциденты, тогда как при строгом соблюдении принципа минимальных привилегий этот показатель падает до 17%.
Анатомия атаки на ИИ-агента через три «средних» бага
Рассмотрим реальный паттерн на примере атаки, построенной вокруг CVE-2025-24813. В компании работает ИИ-ассистент Co-Pilot для отдела Customer Success, размещённый на AWS Bedrock. Его база знаний — экспорт Salesforce в S3-бакете. Логика крутится в Lambda-функциях. Сценарий собрал сотрудник по имени John.
Этап 1: облачный
S3-бакет с клиентскими данными получил слишком широкие права на чтение. В их число попал и John, которому доступ к проду нужен был только для одной миграции два года назад. Сам по себе факт — банальный misconfiguration, помечается как «средний риск» и уходит в конец бэклога. Спокойно, не срочно.
Этап 2: сетевой
На периметре стоит сервер с Apache Tomcat. Уязвимость CVE-2025-24813 (RCE) раскрыта в марте 2025-го, в том же месяце добавлена в каталог CISA KEV. Никто не патчит. Сервер в домене Active Directory — кэшированные учётки лежат в памяти. Тоже «серьёзно, но не критично».
Этап 3: идентификационный
Скомпрометированная учётка AD через Resource-Based Constrained Delegation позволяет атакующему выдать себя за John. Злоумышленник садится в его рабочую станцию, находит там AWS CLI с долгоживущими ключами доступа — и забирает их. Активный Directory сам по себе — тысячи похожих проблем, ничего особенного.
Что получается в сумме
RCE в Tomcat → дамп кредов AD → RBCD-имперсонация → кража AWS-ключей с рабочей станции → доступ к S3-бакету → контроль над базой знаний Co-Pilot. Три средних находки складываются в критический путь. Злоумышленник управляет тем, что агент читает, чему доверяет и что возвращает пользователям. При этом непосредственно ИИ-слой не атакован — скомпрометировано его окружение.
Почему инструменты безопасности не видят проблему
EASM обнаруживает Tomcat и помечает CVE-2025-24813 как умеренный риск — без контекста дальнейшего пути. AD-сканер ругается на RBCD — не видит облака. CSPM сигналит о широких правах на S3 — не знает про AD и сеть. Каждый инструмент выдаёт «moderate finding», приоритет падает, патч откладывается. А в связке это критическая цепочка к ИИ.
Наследование долгов безопасности
ИИ-агент берёт аутентификацию у существующего IdP и тянет за собой его misconfig. Хранит данные в существующем S3 или базе — с их классификацией и избыточными правами. Выполняет задачи через существующие Lambda с их устаревшими рантаймами и слишком жирными IAM-ролями. Инфраструктура готовилась без оглядки на ИИ, а теперь стала его фундаментом.
Что такое exposure management и как его применять
Сначала зависимости ИИ-агента получают статус критических активов: knowledge bases, бакеты, Lambda, интеграции с SaaS, все связующие учётки. Дальше — обратная карта зависимостей: кто и через кого может дотянуться до ИИ. Ищутся эксплуатируемые точки в контексте конкретной среды. Затем — choke points: одно исправление, блокирующее несколько маршрутов. В нашем примере отзыв лишнего доступа John к S3 плюс патч Tomcat плюс починка RBCD обрывают всю цепь разом.
Платформа exposure management должна уметь строить полный путь: устаревший сервер → AD → облако → база знаний ИИ. Если не умеет — никакие guardrails вокруг самого агента не спасут.
Последствия для руководителей ИБ
С каждым новым ИИ-агентом surface атаки растёт, потому что он подключается к уже экспонированной инфраструктуре. Атакующему не нужны новые техники — хватает старых: непропатченных серверов, кривого AD, кражи кредов. Среда сама даёт мост от унаследованного хаоса к новым активам.
Вопрос для CISO сегодня звучит не «защищён ли мой ИИ-слой», а «не отдаёт ли среда, в которой крутятся агенты — со всей нашей legacy-инфраструктурой — путь к их перехвату прямо в руки атакующего».
Что делать прямо сейчас
Инвентаризировать зависимости каждого ИИ-агента и считать их критическими активами. Построить полные пути атак — от периметра через идентичность и облако к базам знаний. Найти и закрыть choke points: одна правка — несколько разорванных цепочек. Внедрить минимальные привилегии — разница между 76% и 17% инцидентов слишком велика, чтобы её игнорировать. Развернуть exposure management с трассировкой между уровнями. Патчить уязвимости из KEV в тот же день — CVE-2025-24813 был в каталоге в марте 2025-го, в том же месяце, что и раскрытие. Аудировать RBCD и прочие делегации в AD — это самый частый вектор бокового перемещения. Убрать долгоживущие облачные ключи с рабочих станций разработчиков — перейти на временные или ротируемые учётки.
И последнее. Атакующим не нужны новые техники, чтобы скомпрометировать ИИ-агентов. Им нужны старые — и среда, которая позволяет использовать старое против нового.
Цифры, от которых становится не по себе
71% организаций хотя бы пилотно внедряют ИИ-агентов в корпоративные приложения. 31% уже перевели их в продакшен. 70% выдают агентам больше привилегий, чем живому сотруднику на аналогичной должности — это данные Infosecurity Magazine. Итог закономерен: 76% компаний с избыточными правами ИИ фиксируют инциденты, тогда как при строгом соблюдении принципа минимальных привилегий этот показатель падает до 17%.
Анатомия атаки на ИИ-агента через три «средних» бага
Рассмотрим реальный паттерн на примере атаки, построенной вокруг CVE-2025-24813. В компании работает ИИ-ассистент Co-Pilot для отдела Customer Success, размещённый на AWS Bedrock. Его база знаний — экспорт Salesforce в S3-бакете. Логика крутится в Lambda-функциях. Сценарий собрал сотрудник по имени John.
Этап 1: облачный
S3-бакет с клиентскими данными получил слишком широкие права на чтение. В их число попал и John, которому доступ к проду нужен был только для одной миграции два года назад. Сам по себе факт — банальный misconfiguration, помечается как «средний риск» и уходит в конец бэклога. Спокойно, не срочно.
Этап 2: сетевой
На периметре стоит сервер с Apache Tomcat. Уязвимость CVE-2025-24813 (RCE) раскрыта в марте 2025-го, в том же месяце добавлена в каталог CISA KEV. Никто не патчит. Сервер в домене Active Directory — кэшированные учётки лежат в памяти. Тоже «серьёзно, но не критично».
Этап 3: идентификационный
Скомпрометированная учётка AD через Resource-Based Constrained Delegation позволяет атакующему выдать себя за John. Злоумышленник садится в его рабочую станцию, находит там AWS CLI с долгоживущими ключами доступа — и забирает их. Активный Directory сам по себе — тысячи похожих проблем, ничего особенного.
Что получается в сумме
RCE в Tomcat → дамп кредов AD → RBCD-имперсонация → кража AWS-ключей с рабочей станции → доступ к S3-бакету → контроль над базой знаний Co-Pilot. Три средних находки складываются в критический путь. Злоумышленник управляет тем, что агент читает, чему доверяет и что возвращает пользователям. При этом непосредственно ИИ-слой не атакован — скомпрометировано его окружение.
Почему инструменты безопасности не видят проблему
EASM обнаруживает Tomcat и помечает CVE-2025-24813 как умеренный риск — без контекста дальнейшего пути. AD-сканер ругается на RBCD — не видит облака. CSPM сигналит о широких правах на S3 — не знает про AD и сеть. Каждый инструмент выдаёт «moderate finding», приоритет падает, патч откладывается. А в связке это критическая цепочка к ИИ.
Наследование долгов безопасности
ИИ-агент берёт аутентификацию у существующего IdP и тянет за собой его misconfig. Хранит данные в существующем S3 или базе — с их классификацией и избыточными правами. Выполняет задачи через существующие Lambda с их устаревшими рантаймами и слишком жирными IAM-ролями. Инфраструктура готовилась без оглядки на ИИ, а теперь стала его фундаментом.
Что такое exposure management и как его применять
Сначала зависимости ИИ-агента получают статус критических активов: knowledge bases, бакеты, Lambda, интеграции с SaaS, все связующие учётки. Дальше — обратная карта зависимостей: кто и через кого может дотянуться до ИИ. Ищутся эксплуатируемые точки в контексте конкретной среды. Затем — choke points: одно исправление, блокирующее несколько маршрутов. В нашем примере отзыв лишнего доступа John к S3 плюс патч Tomcat плюс починка RBCD обрывают всю цепь разом.
Платформа exposure management должна уметь строить полный путь: устаревший сервер → AD → облако → база знаний ИИ. Если не умеет — никакие guardrails вокруг самого агента не спасут.
Последствия для руководителей ИБ
С каждым новым ИИ-агентом surface атаки растёт, потому что он подключается к уже экспонированной инфраструктуре. Атакующему не нужны новые техники — хватает старых: непропатченных серверов, кривого AD, кражи кредов. Среда сама даёт мост от унаследованного хаоса к новым активам.
Вопрос для CISO сегодня звучит не «защищён ли мой ИИ-слой», а «не отдаёт ли среда, в которой крутятся агенты — со всей нашей legacy-инфраструктурой — путь к их перехвату прямо в руки атакующего».
Что делать прямо сейчас
Инвентаризировать зависимости каждого ИИ-агента и считать их критическими активами. Построить полные пути атак — от периметра через идентичность и облако к базам знаний. Найти и закрыть choke points: одна правка — несколько разорванных цепочек. Внедрить минимальные привилегии — разница между 76% и 17% инцидентов слишком велика, чтобы её игнорировать. Развернуть exposure management с трассировкой между уровнями. Патчить уязвимости из KEV в тот же день — CVE-2025-24813 был в каталоге в марте 2025-го, в том же месяце, что и раскрытие. Аудировать RBCD и прочие делегации в AD — это самый частый вектор бокового перемещения. Убрать долгоживущие облачные ключи с рабочих станций разработчиков — перейти на временные или ротируемые учётки.
И последнее. Атакующим не нужны новые техники, чтобы скомпрометировать ИИ-агентов. Им нужны старые — и среда, которая позволяет использовать старое против нового.