71% компаний уже тестируют AI-агентов в корпоративных приложениях, а 31% успели довести их до рабочих процессов. Проблема в том, что безопасность AI-агентов часто строят вокруг моделей, промптов и утечек данных, тогда как реальный взлом начинается с куда более прозаичных вещей: старого Tomcat, лишних прав в Active Directory и ключей AWS на ноутбуке разработчика.
Как пишет The Hacker News, именно этот слепой участок описал на Gartner Security & Risk Management Summit в июне 2026 года Зур Улианицки, SVP Product and Security Research в XM Cyber. Его тезис неприятен, но слишком правдоподобен для любого энтерпрайза: злоумышленнику не обязательно атаковать сам AI-агент. Достаточно добраться до инфраструктуры, на которой он держится, и агент сам принесет ему нужные данные, доступы и бизнес-контекст.
Логика здесь простая. AI-агент не живет в вакууме: он ходит в корпоративные хранилища, читает базы знаний, запускает функции, обращается к SaaS-сервисам и аутентифицируется через уже существующие провайдеры идентичности. Иными словами, он наследует весь исторический технический долг компании. Неисправленный сервер, старая сервисная учетная запись, избыточная роль в IAM, кэшированные креды в CLI, забытая делегация в AD, все это внезапно становится частью новой поверхности атаки. Для безопасности AI-агентов это плохая новость: старые уязвимости получают новый, куда более дорогой эффект.
В статье приводят несколько цифр, которые делают картину еще менее академической. По данным Infosecurity Magazine, 70% организаций выдают своим AI-системам больше привилегий, чем получил бы человек на той же роли. Результат ожидаемый: среди компаний с избыточно привилегированными AI-системами о инцидентах сообщили 76%, тогда как при соблюдении принципа least privilege этот показатель составил 17%. Иначе говоря, проблема не только в том, что агент подключен к старой инфраструктуре, но и в том, что ему часто дают слишком широкий пропуск в прод.
Самый показательный фрагмент материала, сценарий компрометации AI-агента без прямой атаки на AI-стек. В примере команда customer success использует Co-Pilot на AWS Bedrock. Он берет клиентские данные из Salesforce, выгруженные в S3, выполняет действия через Lambda и интегрирован с бизнес-приложениями. Разработчик по имени John поддерживает этого агента и управляет ресурсами через AWS CLI. Дальше начинается не научная фантастика, а типовой корпоративный пейзаж. Во-первых, S3-бакет с выгрузкой из Salesforce становится критичным активом, потому что хранит чувствительные данные клиентов. Во-вторых, у нескольких пользователей в AWS-аккаунте слишком широкие права на чтение продовых бакетов, включая самого разработчика, которому такой доступ по факту не нужен. Уже неприятно, но пока еще не катастрофа.
Следующий шаг еще банальнее. На внешнем периметре остается сервер с Apache Tomcat, уязвимый к CVE-2025-24813, дыре для удаленного выполнения кода, раскрытой в марте 2025 года и в том же месяце добавленной CISA в каталог Known Exploited Vulnerabilities. Сервер не пропатчили. Поскольку он включен в домен и связан с Active Directory, атакующий после эксплуатации может вытащить кэшированные учетные данные из памяти и скомпрометировать доменную учетку. Если смотреть на такой инцидент в отрыве, это еще один старый добрый кейс про забытый патч-менеджмент. Таких серверов в крупных компаниях обычно не один и не два.
Критичной атаку делает сцепка с третьим звеном. Скомпрометированная AD-учетка использует ошибку в настройке Resource-Based Constrained Delegation, чтобы выдать себя за John и попасть на его рабочую станцию. Там лежат ключи доступа AWS, потому что разработчик работает через CLI. После этого злоумышленник получает возможность читать весь продовый S3-бакет, который кормит корпоративного Co-Pilot. На этом этапе AI-агент скомпрометирован без единой атаки на модель, промпт или inference-слой: можно менять то, что он читает, влиять на то, чему он доверяет, и искажать то, что он возвращает сотрудникам. Для бизнеса это уже не абстрактная «угроза AI», а прямой риск утечки данных, подмены ответов и ошибок в операционных процессах.
Для разработчиков, платформенных команд и CISO здесь довольно приземленный вывод. Отдельные инструменты обычно видят только кусок проблемы. Один продукт подсветит внешний Tomcat, другой найдет небезопасную делегацию в AD, третий покажет избыточный доступ к S3. По отдельности это может выглядеть как несколько умеренных замечаний, которые легко проигнорировать в квартальном бэклоге. Но если связать их в одну цепочку, получается критический маршрут к AI-активу. Поэтому безопасность AI-агентов в 2026 году, похоже, все меньше про «поставить guardrails» и все больше про нормальный exposure management: считать базы знаний, бакеты, Lambda-функции и интеграционные креды критичными активами, а потом раскручивать назад, кто и через что реально может к ним добраться.
На практике это означает скучные, но полезные вещи: пересматривать права AI-сервисов по принципу least privilege, вычищать доступ разработчиков к продовым данным, убирать долгоживущие ключи с рабочих станций, закрывать старые RCE на периметре и разбирать наследованные настройки AD, которые годами считались просто «особенностью среды». AI-слой здесь лишь ускоритель последствий. Чем больше компаний запускают агентов в прод, тем дороже становится каждая старая инфраструктурная ошибка. Главный вопрос уже не в том, защищена ли сама модель, а в том, сколько старой инфраструктуры вокруг нее все еще работает по логике 2016 года, но теперь управляет решениями 2026-го.