Автономні AI‑агенти у хмарі дедалі активніше керують бізнес‑процесами, але саме вони можуть стати найслабшою ланкою в архітектурі безпеки. Дослідники Palo Alto Networks Unit 42 виявили критичну «сліпу зону» в Google Cloud Vertex AI, яка дозволяє зловмисникам перетворювати AI‑агентів на прихованих «двійних агентів» з доступом до інфраструктури клієнта та його даних.
Як працює Vertex AI та чому P4SA стають проблемою
Vertex AI надає платформу для розробки та запуску AI‑агентів, які автоматично взаємодіють з ресурсами Google Cloud. Для цього Google створює спеціальні сервісні акаунти формату P4SA (Per‑Project, Per‑Product Service Agent) — саме від їхніх прав залежить, що агент зможе робити від імені клієнтського проєкту.
За спостереженнями Unit 42, P4SA‑акаунти, що створюються при розгортанні агентів за допомогою Vertex AI Agent Development Kit (ADK) та Agent Engine, отримують надмірні привілеї за замовчуванням. Кожен виклик агента супроводжується зверненням до metadata‑сервісу Google Cloud, звідки можна отримати токени сервісного акаунта, інформацію про проєкт та OAuth‑області доступу.
Якщо зловмиснику вдається скомпрометувати AI‑агента (через вразливий код, неправильну конфігурацію чи ланцюг постачання ПЗ), він отримує повноваження цього P4SA. Агент продовжує виконувати «легальні» завдання, але паралельно може непомітно виводити дані, виконувати команди в хмарі та закріплюватися в інфраструктурі.
Втеча з контексту AI‑агента та доступ до ресурсів Google Cloud
Дослідники показали, що отримані з metadata‑сервісу облікові дані P4SA дозволяють вийти за межі очікуваного контексту виконання AI‑агента. Фактично зловмисник переходить від рівня окремого сервісу Vertex AI до рівня повноцінного клієнтського проєкту в Google Cloud, що порушує модель ізоляції «сервіс ↔ клієнт».
Використовуючи викрадені токени, Unit 42 змогли організувати читання всіх об’єктів у Google Cloud Storage‑бакетах відповідного проєкту. Для більшості організацій саме GCS є сховищем резервних копій, експорту баз даних, моделей машинного навчання та інших критичних артефактів. У такому сценарії AI‑агент фактично перетворюється на «інсайдера» з доступом «read‑only» до майже всіх даних у межах проєкту.
Окремо дослідники змогли отримати доступ до ресурсів керованого Google тенант‑проєкту, у якому працює Vertex AI Agent Engine. Хоча права були обмежені, сама можливість переглядати Google Cloud Storage у цьому тенанті збільшує поверхню атаки та дає цінну розвідувальну інформацію про внутрішню інфраструктуру платформи.
Artifact Registry та Vertex AI Reasoning Engine: ризики ланцюга постачання
Доступ до приватних контейнерів Vertex AI Reasoning Engine
Найбільш тривожним виявився доступ до Google Artifact Registry. Облікові дані тих самих P4SA‑акаунтів дозволяли звертатися до закритих репозиторіїв та завантажувати контейнерні образи, що використовуються в ядрі Vertex AI Reasoning Engine і не призначені для публічного розповсюдження.
Отримавши такі образи, зловмисник здобуває доступ до пропрієтарного коду, конфігурацій та внутрішніх компонентів платформи. Це створює ризики витоку інтелектуальної власності та надає детальну карту внутрішньої архітектури, яку можна використовувати для пошуку нових вразливостей, помилок конфігурації чи застарілих залежностей.
Порушення безпеки ланцюга постачання ПЗ
Фактично надмірні права доступу до Artifact Registry свідчать про збій у моделі керування доступом до критичної інфраструктури. Навіть якщо можливості змінювати або публікувати образи відсутні, сам факт видимості приватних артефактів дозволяє:
ідентифікувати внутрішні компоненти та їх версії, картувати ланцюг постачання ПЗ Google Cloud і Vertex AI, планувати таргетовані атаки як на саму платформу, так і на клієнтів, що використовують ті ж образи. У контексті зростання атак на ланцюги постачання це становить особливо високий ризик для великих організацій.
Реакція Google та рекомендації з посилення безпеки Vertex AI
У відповідь на звіт Unit 42 компанія Google оновила документацію Vertex AI, детальніше описавши, як сервіс використовує ресурси, сервісні акаунти та агентів. Ключова рекомендація для клієнтів — переходити на власні сервісні акаунти (Bring Your Own Service Account, BYOSA) замість використання акаунтів за замовчуванням та суворо дотримуватися принципу найменших привілеїв (PoLP).
Практично це означає, що AI‑агент повинен мати лише ті ролі й OAuth‑області, які необхідні для його бізнес‑задач, без широких прав на кшталт Editor. Важливо відключати невикористовувані API, регулярно проводити ревізію призначених ролей, а також моніторити аномальну активність сервісних акаунтів через журнали аудиту та SIEM‑системи.
Розгортання AI‑агентів доцільно розглядати так само жорстко, як введення в експлуатацію нового мікросервісу: перевіряти межі доступу й ізоляцію між проєктами, контролювати цілісність вихідного коду та контейнерів, проводити тестування безпеки з фокусом на доступ до metadata‑сервісу, інтегрувати Vertex AI у наявні процеси DevSecOps та управління ризиками. Чим раніше організації переглянуть політики доступу, впровадять BYOSA і централізований моніторинг сервісних акаунтів, тим менша ймовірність того, що їхні AI‑агенти перетворяться з помічників на прихованих «двійних агентів» у хмарній інфраструктурі.
