Palo Alto Networks’ Unit 42 has disclosed a critical security blind spot in Google Cloud Vertex AI that could allow attackers to turn legitimate AI agents into stealthy “double agents,” abusing their access to sensitive data and cloud infrastructure. The weakness stems from how Vertex AI provisions and permissions its default service accounts, rather than from a flaw in the core machine learning models.
How the Vertex AI Security Gap Arises: P4SA Service Accounts and AI Agents
Vertex AI provides tooling for building AI agents that can autonomously make decisions and interact with Google Cloud resources. To execute actions on behalf of these agents, Google automatically creates special service identities known as P4SA (Per‑Project, Per‑Product Service Agents).
According to Unit 42, P4SA accounts created when deploying agents via the Vertex AI Agent Development Kit (ADK) and Agent Engine are often granted excessive default permissions. Every time an AI agent runs, it can access the Google Cloud metadata service, which returns credentials for the service account, project identifiers, and details about the agent’s identity and OAuth scopes.
If an attacker compromises an AI agent—through prompt injection, vulnerable code, misconfiguration, or a third‑party integration—that agent can continue to behave normally while silently exfiltrating data, issuing commands as the P4SA account, and establishing long‑term persistence in the cloud environment.
Abusing the Metadata Service to Escape the Vertex AI Execution Context
Unit 42 demonstrated that once P4SA credentials are obtained from the metadata service, an attacker can operate outside the expected Vertex AI sandbox and directly within the customer’s Google Cloud project. This breaks the isolation many organizations assume exists between managed AI services and their own resources.
Using stolen P4SA tokens, the researchers were able to read all objects in Google Cloud Storage (GCS) buckets within the affected project. In practice, these buckets frequently host database exports, backups, ML models, logs, and other highly sensitive assets. The AI agent effectively gains “read‑only insider” capabilities across the project’s data plane, even though its intended function may be limited to a narrow business task.
Visibility into Google‑Managed Tenant Projects
Vertex AI Agent Engine runs in a separate Google‑managed tenant project. Unit 42 showed that the same P4SA credentials can reach GCS resources in this tenant project as well. While the researchers lacked full access to bucket contents, the mere ability to list and inspect internal storage locations expands the attack surface and offers valuable reconnaissance into Google’s underlying platform architecture.
Artifact Registry Exposure and AI Software Supply Chain Risks
Access to Private Vertex AI Reasoning Engine Images
The most sensitive finding involved Google Artifact Registry. Unit 42 discovered that P4SA permissions allowed access to private repositories containing container images used by the Vertex AI Reasoning Engine—components that are not intended for public distribution.
By pulling these internal images, an attacker could inspect proprietary code, configuration files, and dependency trees. This not only risks leakage of intellectual property but also provides a detailed map of internal architecture that could be mined for new vulnerabilities, misconfigurations, or outdated libraries.
Implications for the Cloud Software Supply Chain
Excessive Artifact Registry privileges illustrate a broader issue: weak access control around core platform components can ripple into the cloud software supply chain. Even with limited permissions, an attacker able to enumerate internal images can:
– map the build and deployment pipeline for Google Cloud and Vertex AI components;
– identify legacy or potentially vulnerable images for targeted research;
– plan follow‑on attacks against the platform or customer workloads that rely on the same components.
Google’s Response and Vertex AI Security Best Practices for Customers
Google has updated its Vertex AI documentation to clarify how agents, service accounts, and resources are used. A central recommendation is for customers to adopt Bring Your Own Service Account (BYOSA) and rigorously apply the principle of least privilege (PoLP).
In practical terms, this means assigning AI agents only the specific permissions required for their role, avoiding broad roles such as Editor, and tightly constraining OAuth scopes. Organizations should also disable unused APIs, regularly review IAM bindings, and monitor service account activity with tools such as Cloud Logging, Cloud Audit Logs, and Security Command Center.
From a governance perspective, deploying AI agents should be treated like onboarding a new microservice into production. Security teams should validate project isolation, enforce image and code integrity checks, test for metadata service abuse, and integrate agent deployments into existing DevSecOps workflows and risk management processes, aligning with guidance from frameworks such as NIST SP 800‑204 and emerging AI security best practices.
As generative AI and autonomous agents become deeply embedded in business processes, they inevitably become high‑value targets. Organizations using Vertex AI or similar platforms should proactively harden their environments: implement BYOSA with least privilege, centralize monitoring of service accounts, and conduct recurring configuration and permissions reviews. Doing so reduces the likelihood that helpful AI assistants will be repurposed as invisible “double agents” operating inside the cloud perimeter.
