Исследователи Palo Alto Networks Unit 42 сообщили о критическом «слепом пятне» в механизмах безопасности Google Cloud Vertex AI, которое позволяет злоумышленникам использовать AI‑агентов для несанкционированного доступа к данным и инфраструктуре клиента. Проблема связана с моделью разрешений платформы и избыточными правами сервисных аккаунтов по умолчанию.
Как устроена уязвимость Vertex AI и почему страдают AI‑агенты
Vertex AI предоставляет средства для разработки и запуска AI‑агентов, способных автоматически принимать решения и взаимодействовать с облачными ресурсами. Для работы таких агентов Google создает специальные сервисные аккаунты формата P4SA (Per‑Project, Per‑Product Service Agent), через которые выполняются операции в Google Cloud.
По данным Unit 42, именно эти P4SA‑аккаунты, создаваемые при развертывании AI‑агента с помощью Vertex AI Agent Development Kit (ADK) и Agent Engine, получают чрезмерно широкие права по умолчанию. В результате любой вызов агента приводит к обращению к метадата‑сервису Google Cloud, откуда можно извлечь учетные данные сервисного аккаунта и информацию о проекте, идентичности агента и назначенных ему OAuth‑областях (scopes).
Если злоумышленнику удается скомпрометировать или неправильно сконфигурированный агент, он фактически превращается в «двойного агента»: внешне продолжает выполнять полезные задачи, но параллельно может скрытно выводить данные, выполнять команды от имени сервисного аккаунта и создавать долговременные точки присутствия в облаке.
Переход между контекстами и доступ к данным в Google Cloud
Эксперты Unit 42 показали, что, получив учетные данные P4SA из метадата‑сервиса, можно выйти за пределы контекста выполнения AI‑агента и действовать в рамках клиентского проекта Google Cloud. Это нарушает ожидаемую изоляцию между сервисом Vertex AI и ресурсами заказчика.
Используя такие украденные токены, исследователи смогли получить чтение всех данных в Google Cloud Storage‑бакетах соответствующего проекта. Для многих организаций именно в GCS хранятся резервные копии, выгрузки баз данных, модели машинного обучения и прочие чувствительные артефакты. В результате AI‑агент из инструмента автоматизации превращается в эквивалент инсайдера с доступом «только на чтение», но практически ко всем данным проекта.
Доступ к Google‑управляемому тенант‑проекту
Vertex AI Agent Engine работает внутри отдельного, управляемого Google тенант‑проекта. Unit 42 смогли использовать те же P4SA‑учетные данные для доступа к хранилищам Google Cloud Storage в этом тенанте и получения сведений о внутренней инфраструктуре платформы. Хотя прав на чтение содержимого бакетов не хватало, уже один факт видимости таких ресурсов расширяет поверхность атаки и дает злоумышленнику дополнительную разведывательную информацию.
Компрометация Artifact Registry и риски для цепочки поставок ПО
Доступ к приватным образам Vertex AI Reasoning Engine
Наиболее тревожной частью исследования стал доступ к Google Artifact Registry. Было обнаружено, что те же P4SA‑учетные данные позволяют обращаться к закрытым репозиториям и скачивать контейнерные образы, используемые в ядре Vertex AI Reasoning Engine. Речь идет о компонентах, которые не предназначены для публичного распространения.
Извлекая такие образы, атакующий получает доступ к проприетарному коду и конфигурациям. Это создает не только риск утечки интеллектуальной собственности, но и предоставляет подробную карту внутренней архитектуры, на основе которой можно искать новые уязвимости, слабые места конфигураций и устаревшие компоненты.
Угроза для внутренней цепочки поставок
По сути, неправильно настроенные права доступа в Artifact Registry демонстрируют сбой в управлении доступом к критичной инфраструктуре. Наличие видимости закрытых образов, даже без полного набора прав, может позволить злоумышленнику:
– картировать внутреннюю цепочку поставок ПО Google Cloud и Vertex AI;
– идентифицировать потенциально уязвимые или устаревшие образы;
– планировать дальнейшие атаки на инфраструктуру или клиентов, использующих те же компоненты.
Реакция Google и рекомендации по защите Vertex AI
Google обновила официальную документацию по Vertex AI, детализировав, как сервис использует ресурсы, аккаунты и агентов. Ключевая рекомендация для клиентов — использовать собственные сервисные аккаунты (Bring Your Own Service Account, BYOSA) вместо аккаунтов по умолчанию и строго применять принцип минимально необходимых привилегий (PoLP).
Практически это означает, что AI‑агенту должны выдаваться только те права, которые необходимы для выполнения его задач, без широких ролей уровня Editor или аналогичных. Необходимо ограничивать OAuth‑области, отключать неиспользуемые API, регулярно пересматривать назначенные роли и мониторить использование сервисных аккаунтов.
Исследователи Unit 42 подчеркивают, что развертывание AI‑агентов следует рассматривать так же строго, как ввод в эксплуатацию нового продукта или микросервиса. Перед переносом в продакшн важно:
– валидировать границы прав и изоляцию между проектами;
– проводить контроль целостности исходного кода и контейнерных образов;
– выполнять управляемое тестирование безопасности, включая попытки доступа к метадата‑сервису;
– настраивать аудит и оповещения по аномальной активности сервисных аккаунтов.
Расширение использования генеративных моделей и автономных AI‑агентов делает их привлекательной целью для атак. Организациям, использующим Vertex AI и аналогичные AI‑платформы, имеет смысл пересмотреть свои политики управления доступом, внедрить BYOSA, централизованный мониторинг сервисных аккаунтов и регулярные проверки конфигураций. Чем раньше AI‑агенты будут интегрированы в существующие процессы DevSecOps и управления рисками, тем ниже вероятность того, что они превратятся из помощников в невидимых «двойных агентов» внутри облака.
