Исследователи из Palo Alto Networks Unit 42 обнаружили серьёзную уязвимость в платформе Google Cloud's Vertex AI. Проблема не в экзотическом баге — она заложена в самой архитектуре разрешений по умолчанию, которые получает каждый развёрнутый ИИ-агент. Именно это делает её особенно опасной: всё работает штатно, никаких видимых сбоев, а атака уже идёт.
Суть уязвимости связана с механизмом под названием Per-Project, Per-Product Service Agent, или P4SA. Когда разработчик разворачивает ИИ-агента через Vertex AI Agent Development Kit (ADK) и запускает его через Agent Engine, агент автоматически получает сервисный аккаунт с широким набором прав. Каждый вызов агента обращается к Google's metadata service — и именно в этот момент наружу утекает критически важная информация: учётные данные сервисного агента, идентификатор проекта GCP, личность самого агента и права машины, на которой он работает.
Исследователь Unit 42 Офир Шати описал это как угрозу «двойного агента»: скомпрометированный или намеренно сконфигурированный агент внешне функционирует нормально, но параллельно вытаскивает данные, ломает изоляцию инфраструктуры и создаёт бэкдоры. Никаких предупреждений, никаких очевидных следов.
Получив учётные данные P4SA, атакующий может совершить так называемый «прыжок контекста» — перейти из окружения исполнения агента прямо в клиентский проект. Это уничтожает гарантии изоляции, которые должна обеспечивать платформа. Результат: неограниченный доступ на чтение ко всем данным в Google Cloud Storage buckets конкретного проекта. Не к части данных — ко всем.
Дальше хуже. Agent Engine работает внутри управляемого Google tenant-проекта, и украденные учётные данные дают видимость в Cloud Storage buckets этого тенанта, раскрывая детали внутренней инфраструктуры Google. Доступа к самим бакетам у этих credentials не было — прав не хватало — но сам факт видимости уже говорит о многом.
Отдельная история с Artifact Registry. Те же P4SA-учётные данные открывали доступ к закрытым репозиториям, принадлежащим Google. Эти репозитории всплывали в процессе деплоя через Agent Engine. Из них можно было скачать контейнерные образы, составляющие ядро Vertex AI Reasoning Engine. Содержимое логов деплоя дополнительно раскрывало список образов и давало доступ к другим закрытым репозиториям Artifact Registry.
По оценке Unit 42, это не просто утечка данных конкретной организации. Атакующий получает карту внутренней цепочки поставок программного обеспечения Google, может находить устаревшие или уязвимые образы и использовать их как трамплин для дальнейших атак. Плюс — прямой доступ к интеллектуальной собственности компании в виде проприетарного кода.
Google в ответ обновила официальную документацию Vertex AI, добавив разъяснения о том, как платформа использует ресурсы, аккаунты и агентов. Кроме того, компания рекомендует клиентам переходить на схему Bring Your Own Service Account (BYOSA) — то есть заменять дефолтный сервисный аккаунт собственным, с явно прописанными правами. И обязательно применять Principle of Least Privilege (PoLP): агент должен иметь ровно те разрешения, которые нужны для его конкретных задач, и ни одного лишнего.
Офир Шати и команда Unit 42 сформулировали практические шаги для организаций, которые уже используют или планируют использовать Vertex AI. Деплой ИИ-агента нужно рассматривать с той же строгостью, что и выкатку нового production-кода: проверять границы разрешений, ограничивать OAuth scopes до минимально необходимых, контролировать целостность источников и проводить security-тестирование до того, как агент уходит в продакшн. Не после.
Показательно, что эта уязвимость появилась не из-за ошибки программиста в конкретной строке кода. Она вытекает из архитектурного решения — выдавать широкие права по умолчанию, чтобы агент просто работал из коробки. Удобство разработчиков оказалось в прямом конфликте с безопасностью. И пока организации не начнут активно переконфигурировать дефолтные настройки Vertex AI, эта точка входа остаётся открытой.
Изображение носит иллюстративный характер
Суть уязвимости связана с механизмом под названием Per-Project, Per-Product Service Agent, или P4SA. Когда разработчик разворачивает ИИ-агента через Vertex AI Agent Development Kit (ADK) и запускает его через Agent Engine, агент автоматически получает сервисный аккаунт с широким набором прав. Каждый вызов агента обращается к Google's metadata service — и именно в этот момент наружу утекает критически важная информация: учётные данные сервисного агента, идентификатор проекта GCP, личность самого агента и права машины, на которой он работает.
Исследователь Unit 42 Офир Шати описал это как угрозу «двойного агента»: скомпрометированный или намеренно сконфигурированный агент внешне функционирует нормально, но параллельно вытаскивает данные, ломает изоляцию инфраструктуры и создаёт бэкдоры. Никаких предупреждений, никаких очевидных следов.
Получив учётные данные P4SA, атакующий может совершить так называемый «прыжок контекста» — перейти из окружения исполнения агента прямо в клиентский проект. Это уничтожает гарантии изоляции, которые должна обеспечивать платформа. Результат: неограниченный доступ на чтение ко всем данным в Google Cloud Storage buckets конкретного проекта. Не к части данных — ко всем.
Дальше хуже. Agent Engine работает внутри управляемого Google tenant-проекта, и украденные учётные данные дают видимость в Cloud Storage buckets этого тенанта, раскрывая детали внутренней инфраструктуры Google. Доступа к самим бакетам у этих credentials не было — прав не хватало — но сам факт видимости уже говорит о многом.
Отдельная история с Artifact Registry. Те же P4SA-учётные данные открывали доступ к закрытым репозиториям, принадлежащим Google. Эти репозитории всплывали в процессе деплоя через Agent Engine. Из них можно было скачать контейнерные образы, составляющие ядро Vertex AI Reasoning Engine. Содержимое логов деплоя дополнительно раскрывало список образов и давало доступ к другим закрытым репозиториям Artifact Registry.
По оценке Unit 42, это не просто утечка данных конкретной организации. Атакующий получает карту внутренней цепочки поставок программного обеспечения Google, может находить устаревшие или уязвимые образы и использовать их как трамплин для дальнейших атак. Плюс — прямой доступ к интеллектуальной собственности компании в виде проприетарного кода.
Google в ответ обновила официальную документацию Vertex AI, добавив разъяснения о том, как платформа использует ресурсы, аккаунты и агентов. Кроме того, компания рекомендует клиентам переходить на схему Bring Your Own Service Account (BYOSA) — то есть заменять дефолтный сервисный аккаунт собственным, с явно прописанными правами. И обязательно применять Principle of Least Privilege (PoLP): агент должен иметь ровно те разрешения, которые нужны для его конкретных задач, и ни одного лишнего.
Офир Шати и команда Unit 42 сформулировали практические шаги для организаций, которые уже используют или планируют использовать Vertex AI. Деплой ИИ-агента нужно рассматривать с той же строгостью, что и выкатку нового production-кода: проверять границы разрешений, ограничивать OAuth scopes до минимально необходимых, контролировать целостность источников и проводить security-тестирование до того, как агент уходит в продакшн. Не после.
Показательно, что эта уязвимость появилась не из-за ошибки программиста в конкретной строке кода. Она вытекает из архитектурного решения — выдавать широкие права по умолчанию, чтобы агент просто работал из коробки. Удобство разработчиков оказалось в прямом конфликте с безопасностью. И пока организации не начнут активно переконфигурировать дефолтные настройки Vertex AI, эта точка входа остаётся открытой.
