Incident Overview
In March 2026, researchers from Palo Alto Networks Unit 42 demonstrated a critical security flaw in Google Cloud’s Vertex AI platform. The vulnerability allowed a compromised AI agent, deployed using Vertex AI’s Agent Engine and Application Development Kit (ADK), to escalate privileges beyond its intended scope. By exploiting inherited Google-managed credentials—specifically the Per-Project, Per-Product Service Agent (P4SA)—the agent pivoted from a customer project into restricted Google infrastructure, including internal Artifact Registry repositories and Google Cloud Storage buckets.
The attack began with the deployment of a malicious AI agent, crafted using the ADK and configured to extract service-agent credentials from Google’s metadata service. The agent’s instructions explicitly directed it to exfiltrate data from storage buckets, while its underlying code included libraries for network requests, subprocess execution, and operating system interactions. Once deployed, the agent queried Google’s metadata service to retrieve the credentials of the service account associated with Vertex AI’s Reasoning Engine: service-<PROJECT-ID>@gcp-sa-aiplatform-re.iam.gserviceaccount.com.
With these stolen credentials, the researchers achieved unauthorized access to two critical environments: the consumer project (the customer’s own Google Cloud project) and the producer project (Google’s internal infrastructure hosting Vertex AI). In the consumer project, the agent gained unrestricted read access to all Google Cloud Storage buckets, effectively bypassing project isolation. In the producer project, the agent accessed restricted Artifact Registry repositories, downloading proprietary container images central to Vertex AI’s Reasoning Engine, including us-docker.pkg.dev/cloud-aiplatform-private/reasoning-engine and related extensions. These images contained proprietary code and internal deployment configurations, exposing Google’s intellectual property and potential vulnerabilities.
The researchers also discovered that the compromised credentials allowed enumeration of additional restricted repositories within Google’s Artifact Registry. This unintended visibility revealed other container images and internal artifacts, further compromising Google’s software supply chain. Additionally, the agent accessed sensitive deployment files in the tenant project’s storage, including a Dockerfile.zip containing hardcoded internal details about Google’s infrastructure.
Google responded by revising its documentation to clarify how Vertex AI uses resources, accounts, and agents. No CVE was assigned, as the issue stemmed from default permission scoping and design choices rather than a traditional code vulnerability. Google also recommended adopting Bring Your Own Service Account (BYOSA) to enforce the principle of least privilege for Agent Engine deployments, mitigating the risk of excessive permissions.
This incident underscores the risks of delegating broad permissions to AI agents, particularly when those agents inherit Google-managed identities. The misuse of P4SA credentials transformed a benign AI tool into an insider threat capable of data exfiltration, infrastructure compromise, and intellectual property theft. The findings highlight the need for stricter access controls, continuous monitoring of agent permissions, and adherence to least-privilege principles in AI-driven environments.
Possible Root Cause
The primary root cause of this vulnerability was the excessive default permissions assigned to the Per-Project, Per-Product Service Agent (P4SA) associated with Vertex AI agents. When an AI agent is deployed via the Agent Engine and ADK, it inherits the P4SA’s credentials, which include broad access to Google Cloud resources. The P4SA’s default permissions were not constrained to the agent’s intended scope, allowing it to interact with resources outside the customer’s project, including Google’s internal infrastructure.
The P4SA’s permissions included unrestricted access to Google Cloud Storage buckets and the ability to query Google’s metadata service. This design choice enabled the agent to extract service-account credentials and pivot into restricted environments. Specifically, the P4SA had permissions tied to the Vertex AI Reasoning Engine’s service account, which granted access to Google’s internal Artifact Registry repositories and tenant project storage. These repositories housed proprietary container images and deployment artifacts, none of which were accessible to standard customer-managed identities.
The vulnerability arose from two interconnected design flaws:
- Over-Permissive Defaults: The P4SA was granted permissions far beyond what a typical AI agent requires, violating the principle of least privilege.
- Inherited Google-Managed Identity: Vertex AI agents inherit Google-managed service accounts, which are not subject to the same access controls as customer-managed identities. This inheritance model created a blind spot where an attacker could exploit the agent’s elevated privileges to move laterally within Google’s infrastructure.
The researchers demonstrated that by deploying a malicious agent with specific instructions—such as exfiltrating data from storage buckets—they could trigger the extraction of P4SA credentials via a metadata service query. This query returned JSON-formatted credentials, which were then used to authenticate requests to restricted resources. The absence of granular access controls or runtime permission checks further exacerbated the risk, as the agent could freely enumerate and access repositories without detection.
Google’s response to this issue involved revising its documentation to explicitly warn about the risks of default permission scoping. However, the underlying design flaw persisted, as the revision did not alter the default behavior of P4SA permissions. The recommended mitigation—Bring Your Own Service Account (BYOSA)—aims to address this by allowing customers to define custom service accounts with tailored permissions, reducing the attack surface. Yet, the incident reveals a broader challenge: the reliance on inherited, Google-managed identities in AI agent deployments introduces inherent risks that cannot be fully mitigated through documentation alone.
Takeaways
This incident serves as a critical case study in the security risks associated with AI agents, particularly those deployed in cloud environments like Google Vertex AI. The findings highlight several key lessons for organizations adopting AI-driven automation and developers building agentic systems:
- Their permissions must be rigorously audited and constrained to the minimum necessary for operation. The principle of least privilege is not optional but a requirement in environments where agents interact with sensitive data or infrastructure.
- Default Permissions Are a Liability: The excessive permissions assigned to the P4SA demonstrate how default configurations can become attack vectors. Organizations must avoid relying on default settings for service accounts, particularly in AI-driven workflows where agents may interact with multiple projects or cloud services. Custom service accounts with explicit, limited permissions should be the standard.
- Inherited Identities Introduce Blind Spots: When AI agents inherit Google-managed or third-party identities, they bypass traditional access controls. This inheritance model can create unintended pathways for lateral movement, as seen in this incident. Organizations should evaluate whether inherited identities are necessary and, if so, implement additional layers of monitoring and validation to detect anomalous behavior.
- Artifact Registry and Supply Chain Risks: The exposure of Google’s internal Artifact Registry repositories reveals the broader risks of misconfigured access controls in cloud-native environments. Attackers who gain access to proprietary container images or deployment artifacts can map internal software supply chains, identify vulnerabilities, and plan further attacks. Organizations must enforce strict access controls over artifact repositories and monitor for unauthorized enumeration attempts.
- Monitoring and Detection Gaps: The incident highlights the need for continuous monitoring of AI agent activities, particularly those involving service account interactions.
- Collaboration Between Researchers and Vendors: The responsible disclosure process between Palo Alto Networks Unit 42 and Google resulted in documentation updates and mitigation recommendations. Vendors must proactively engage with security researchers to identify and address design flaws before they are weaponized, while organizations should participate in bug bounty programs or private disclosures to stay informed about emerging threats.
- The Need for BYOSA and Custom Permissions: Google’s recommendation to adopt Bring Your Own Service Account (BYOSA) is a step toward mitigating inherited identity risks. Organizations should evaluate whether BYOSA is feasible for their AI deployments and work with cloud providers to implement custom service accounts with granular permissions.
- Intellectual Property and Internal Infrastructure Risks: The unauthorized access to Google’s proprietary container images and internal deployment files demonstrates how AI agent vulnerabilities can extend beyond data exfiltration to intellectual property theft and infrastructure compromise. Organizations must recognize that AI-driven automation can become a vector for targeting not only customer data but also internal R&D, source code, and proprietary tools. This risk necessitates treating AI agents as potential insider threats and applying the same security rigor used for human users or system administrators.
- Documentation Alone Is Not Enough: While Google revised its documentation to warn about default permission risks, the incident shows that documentation changes do not inherently fix design flaws. Organizations must go beyond reading vendor documentation and actively audit their AI deployments for permission creep, inherited identities, and unintended access paths. Regular security assessments, such as those offered by Palo Alto Networks’ Unit 42 AI Security Assessment, can help identify and remediate such risks proactively.