В начале этого месяца я выступил на саммите Gartner Security & Risk Management Summit с докладом о «слепой зоне», которую до сих пор не учитывают большинство программ безопасности, — о том, как злоумышленники обходят системы безопасности на базе ИИ, используя устаревшую инфраструктуру для взлома агентов ИИ.
Внедрение ИИ происходит быстрее, чем успевают реагировать программы безопасности. Примерно 71 % организаций тестируют агенты ИИ в своих корпоративных приложениях, а 31 % уже внедрили их в производственные рабочие процессы.
По этой причине организации вполне обоснованно вкладывают ресурсы в защиту ИИ-рабочих нагрузок от «отравления» моделей, внедрения подсказок, утечки данных и других новых угроз. Однако при таком подходе упускается из виду всё, что находится под слоем ИИ. Ведь незапатченный сервер, неправильно настроенные права доступа в Active Directory или кэшированные учетные данные на компьютере разработчика — все это уязвимости, которые дают злоумышленникам прямой доступ ко всему, от чего зависят ваши агенты ИИ: базам знаний, облачному хранилищу, функциям Lambda, интеграциям SaaS и учетным данным, которые их связывают.
Это означает, что злоумышленникам на самом деле не нужно атаковать ваш ИИ напрямую — им достаточно добраться до того, с чем он связан. В этой статье я расскажу, как устаревшая инфраструктура становится путем атаки на среды агентов ИИ и что могут сделать команды безопасности, чтобы заблокировать эти пути.
Несмотря на свою новизну и мощь, в некоторых отношениях ИИ-агенты работают так же, как и другие ресурсы в вашей среде. Они проходят аутентификацию через существующих поставщиков идентификации, хранят данные в существующих облачных хранилищах, выполняют задачи с помощью существующих функций Lambda и наследуют разрешения от существующих ролей IAM. Каждая из этих зависимостей несет в себе тот «долг безопасности», который существовал в организации до начала развертывания ИИ.
Более того, большинство организаций невольно усугубляют этот долг. По данным журнала Infosecurity Magazine, 70 % организаций предоставляют своим системам ИИ более привилегированный доступ, чем человеку, занимающему ту же должность. Неудивительно, что это обходится им дорого. Организации, в которых ИИ обладает чрезмерными привилегиями, сообщили о частоте инцидентов на уровне 76 %, в то время как у тех, кто придерживается принципа минимальных привилегий, этот показатель составляет всего 17 %.
Все эти подключения — поставщики идентификации, облачные хранилища, функции Lambda, роли IAM — проходят через инфраструктуру, которой ваши команды управляют уже много лет: Active Directory, облачный IAM, служебные учетные записи, сохраненные учетные данные. Однако ни одна из этих компонент не была разработана с учетом ИИ-агентов, и большая часть из них была развернута задолго до того, как первый агент был запущен в производственную среду. В результате злоумышленнику, проникшему через любой из этих уровней, не нужно даже прикасаться к ИИ. Все работу за него делают собственные права доступа агента.
Как уязвимость CVE 2025 года позволяет взломать ИИ-агента в 2026 году
На приведенной ниже схеме показана типичная архитектура корпоративного ИИ-агента. Команда по работе с клиентами использует Co-Pilot на базе ИИ, размещенный на AWS Bedrock, для запроса данных о клиентах, экспортированных из Salesforce в корзину S3. Co-Pilot выполняет задачи с помощью функций Lambda и интегрируется с бизнес-приложениями. Разработчик Джон создает и обслуживает этот агент. Пользователи по всей организации взаимодействуют с ним ежедневно.
А вот что происходит, когда злоумышленник находит способ проникнуть в систему. На следующей схеме показан путь атаки, смоделированный моей командой в реальной корпоративной среде. Ни одна из этих уязвимостей не является чем-то экзотическим — в той или иной комбинации они существуют в большинстве корпоративных сетей уже сейчас. Опасность их заключается в том, как они взаимосвязаны. Вот как развивалась атака, этап за этапом.
Этап 1: Контейнер S3 становится критически важным активом. Для заполнения данных в CSM Co-Pilot команда экспортировала данные из Salesforce в контейнер S3. Этот экспорт превратил контейнер в ценную цель, содержащую конфиденциальные записи о клиентах. Несколько пользователей в рамках одной учетной записи AWS получили чрезмерно широкий доступ на чтение к производственным корзинам S3 — в том числе Джон, разработчик Co-Pilot, которому никогда не требовался доступ к производственным данным. Сама по себе это простая ошибка в настройке прав доступа.
Этап 2: Незапатченный сервер на периметре. На сервере, обращенном во внешнюю сеть, работает Apache Tomcat. Этот сервер уязвим для CVE-2025-24813 — уязвимости, позволяющей удаленно выполнить код, раскрытой в марте 2025 года и добавленной в тот же месяц в каталог CISA «Известные эксплуатируемые уязвимости». Исправление на него так и не было установлено. Поскольку сервер находится в корпоративной среде и подключен к Active Directory, злоумышленник, воспользовавшийся этой уязвимостью, может выгрузить кэшированные учетные данные из памяти сервера и скомпрометировать учетную запись пользователя AD. Сама по себе это известная уязвимость на отдельном сервере — серьезная, но не критическая.
Этап 3: Неправильная настройка Active Directory позволяет осуществлять латеральное перемещение. Скомпрометированная учетная запись AD может злоупотребить неправильной настройкой «Делегирования с ограничением на основе ресурсов» (Resource-Based Constrained Delegation), чтобы выдать себя за Джона и получить доступ к его рабочей станции. Джон использует AWS CLI для управления облачными ресурсами Co-Pilot, и в фоновом режиме CLI хранит ключи доступа к AWS на его компьютере. Злоумышленник перехватывает эти ключи. Сама по себе это проблема с правами доступа в AD — одна из тысяч, которые присутствуют в большинстве сред.
Теперь свяжем эти три этапа воедино. Злоумышленник использует уязвимость CVE-2025-24813 на периметре, извлекает учетные данные, перемещается по AD к рабочей станции Джона, получает его ключи доступа к AWS и считывает каждую запись в производственном бакете S3 — том самом, который питает базу знаний Co-Pilot. Агент Co-Pilot теперь скомпрометирован. Злоумышленник контролирует, что он считывает, чему доверяет и что возвращает пользователям. Ни одна часть стека ИИ не подверглась прямой атаке. Три уязвимости средней степени риска — облачный ключ с избыточными привилегиями, веб-сервер без исправлений и неправильная настройка AD — превратились в один критический путь атаки.
Путь атаки, который я только что описал, проходит через четыре уровня: сеть, идентификацию, облако и ИИ. Большинство программ безопасности оценивают каждый из этих уровней независимо, и уязвимости на каждом из них, возможно, уже известны. Инструмент EASM выявляет проблему с сервером Tomcat. Инструмент безопасности AD обнаруживает неправильную настройку делегирования. Инструмент CSPM обнаруживает доступ к S3 с чрезмерными привилегиями. Каждый из них сообщает об уязвимости средней степени, которая может не устраняться из-за низкого приоритета, но в совокупности они превращаются в критическую проблему: уязвимость Tomcat на периметре проникает через AD к облачным учетным данным разработчика и заканчивается в базе знаний агента ИИ.
Устранение этих путей начинается с подхода к управлению уязвимостями, при котором зависимости агента ИИ (базы знаний, хранилища, функции Lambda и т. д.) рассматриваются как критически важные активы сами по себе. Далее следует проследить путь в обратном направлении: какие отношения идентичности, разрешения и инфраструктура связаны с этими активами, и какие из этих связей несут в себе уязвимости, которые можно использовать в контексте вашей среды? При прослеживании полного пути выявляются узкие места — точки, где одно исправление заблокирует сразу несколько путей к вашим ИИ-активам.
Если ваша платформа управления уязвимостями способна проследить этот полный путь — от устаревшего сервера через Active Directory и облачную инфраструктуру до базы знаний ИИ-агента — вы сможете устранить уязвимость до того, как злоумышленник воспользуется ею. Если же она не способна этого сделать, никакие защитные меры на уровне ИИ не смогут устранить эту уязвимость.
Внедрение ИИ-агентов ускоряется во всех подразделениях предприятий. И каждый новый агент, который вы развертываете, подключается к инфраструктуре, которая уже подвержена риску. Это означает, что с каждым развертыванием площадь атаки увеличивается.
Вопрос для руководителей служб безопасности заключается не в том, защищен ли ваш уровень ИИ. А в том, предоставляет ли среда, в которой работают эти агенты — включая вашу основную устаревшую инфраструктуру — злоумышленникам путь для их взлома.
Ведь злоумышленникам не нужны новые методы для взлома ИИ-агентов. Им достаточно старых — и среды, которая позволяет им использовать старые методы для эксплуатации новых.
Примечание: эта статья была тщательно подготовлена и предоставлена для наших читателей Зуром Улианицким (Zur Ulianitzky), старшим вице-президентом по продуктам и исследованиям в области безопасности компании XM Cyber.