Vertex AI vulnerability exposes private data and artifacts on Google Cloud
Vertex AI, Google Cloud’s artificial intelligence platform, is at the center of a concerning discovery made by researchers at Unit 42, the security team at Palo Alto Networks. A vulnerability found in the platform’s permissions model could turn AI agents into real insider threats, capable of exposing sensitive credentials and compromising entire cloud environments.
The flaw is tied to the excessive permissions granted by default to a component called P4SA, the service agent associated with each project. When an agent is deployed through the Agent Engine, this mechanism automatically exposes critical information, including the service agent’s credentials, the Google Cloud project hosting the agent, and the scopes of the machine responsible for execution.
In other words, an agent that was supposed to be working for you could actually be working against you without anyone noticing.
According to Ofir Shaty, a Unit 42 researcher, a misconfigured or compromised agent can become a double agent that appears to carry out its intended function while, behind the scenes, it exfiltrates sensitive data, compromises infrastructure, and creates backdoors into an organization’s most critical systems. The worst part is that this doesn’t require a sophisticated attack. All it takes is one misconfigured or compromised agent for an attacker to move laterally within the cloud environment, access stored data, private repositories, and even map Google’s internal software supply chain. 😬
What is P4SA and why it sits at the heart of the problem
To understand how serious this is, we need to take a step back and look at the role P4SA plays within the Vertex AI architecture. P4SA, which stands for Per-Project, Per-Product Service Agent, is a component automatically created by Google Cloud whenever a new project uses Vertex AI services. It works as a service identity — essentially an automated user that has permission to perform tasks within the platform on behalf of the project.
The problem starts right there: this service agent receives a fairly broad set of permissions by default, which in theory makes it easier to operate platform resources, but in practice opens a dangerous window when something goes sideways.
When a developer deploys an AI agent using the Vertex AI Agent Engine and Agent Development Kit (ADK), P4SA steps in with all its permissions already configured. This means the deployed agent automatically inherits access to a range of resources in the Google Cloud environment, without the developer needing to manually configure anything.
Receive the best innovation content in your email.
All the news, tips, trends, and resources you're looking for, delivered to your inbox.
By subscribing to the newsletter, you agree to receive communications from Método Viral. We are committed to always protecting and respecting your privacy.
This automation, which exists to make life easier for developers, turns out to be exactly the point that Unit 42 researchers flagged as critical: the agent ends up with access to credentials that should be protected, including authentication tokens, information about the host project, and the execution scopes of the virtual machine running the agent.
What makes this scenario even more concerning is the fact that the exposure doesn’t depend on a complex technical breach or an elaborate exploit. The vulnerability exists in the system’s own operational logic. Any agent that gets compromised — whether through malicious prompt injection or a misconfiguration by the developer — can take advantage of these excessive permissions to perform actions far beyond the original scope it was built for. It’s like handing over the master key to an entire building to someone who should only have access to the conference room on the third floor. 🔑
How this flaw is exploited in practice
Unit 42 researchers demonstrated that exploiting this vulnerability in Vertex AI can happen in distinct ways, and none of them require a high level of technical sophistication.
The first documented path involves the standard agent deployment flow itself. After deploying through the Agent Engine, any call to the agent invokes the Google metadata service, automatically exposing the service agent’s credentials, the GCP project hosting the agent, the agent’s identity, and the scopes of the machine running it. This happens without any additional action from the attacker — they just need access to the agent’s execution context.
The second vector identified is known as indirect prompt injection. In this scenario, an AI agent processing external data — such as documents, emails, or web pages — can receive malicious instructions embedded in that content. The agent, unaware that it’s being manipulated, executes the instructions as if they were part of its normal task, and in the process ends up exposing the P4SA credentials to the attacker. The issue here is that modern agents are designed specifically to consume and interpret large volumes of external data, which significantly increases the attack surface.
The third vector is even more direct: an AI model that has been previously compromised and uploaded to the Google Cloud environment. This is possible because Vertex AI allows users to upload custom models to the platform. If a malicious model is loaded, it can, during execution, access the instance metadata endpoint — an internal Google Cloud service that provides information about the execution environment. When queried from within the environment, this endpoint returns data such as temporary access tokens and other sensitive P4SA information.
Lateral movement and access to Cloud Storage buckets
Unit 42 demonstrated that it was possible to use the stolen credentials to jump from the AI agent’s execution context to the customer’s project, effectively undermining isolation guarantees and allowing unrestricted read access to all Google Cloud Storage buckets within that project. This level of access transforms the AI agent from a useful tool into a potential insider threat, as the researchers themselves described.
Lateral movement is especially dangerous because it allows the attacker to break out of the agent’s isolated context and start interacting with other resources in the Google Cloud project. Depending on the permissions P4SA carries, this can include access to Cloud Storage buckets, reading private repositories in Artifact Registry, querying databases, running machine learning pipelines, and even mapping the project’s internal software dependency structure. In enterprise environments, this kind of access can represent a catastrophic breach, exposing intellectual property, customer data, and critical infrastructure all at once. 😰
Exposure of Google’s internal artifacts and private repositories
But it doesn’t stop there. Because Vertex AI’s Agent Engine runs inside a tenant project managed by Google itself, the extracted credentials also granted access to Cloud Storage buckets within that tenant, revealing additional details about the platform’s internal infrastructure. The researchers noted, however, that in this case the credentials did not have the permissions required to actually access the contents of the exposed buckets.
Still, the same P4SA credentials allowed access to restricted Artifact Registry repositories belonging to Google, which were revealed during the Agent Engine deployment. An attacker could exploit this behavior to download container images from private repositories that make up the core of the Vertex AI Reasoning Engine. Beyond that, the compromised credentials not only allowed downloading the images listed in the logs during deployment but also exposed the full contents of the Artifact Registry repositories, including several other restricted images.
According to Unit 42, gaining access to this proprietary code not only exposes Google’s intellectual property but also gives an attacker a roadmap for finding new vulnerabilities. The misconfigured Artifact Registry reveals an additional flaw in access control management for critical infrastructure, allowing an attacker to map Google’s internal software supply chain, identify deprecated or vulnerable images, and plan follow-up attacks.
What Google did after the discovery
As soon as Unit 42 reported the vulnerability to Google through the responsible disclosure process, the Google Cloud security team acknowledged the issue and initiated the necessary fixes. Google implemented additional controls over the permissions granted by P4SA, with the goal of restricting the scope of access that agents deployed through Agent Engine receive by default. The core idea behind the changes is to apply the principle of least privilege — ensuring that each component only has access to what is strictly necessary to perform its function, and nothing beyond that.
In addition to fixing the permissions model, Google updated its official documentation to clearly explain how Vertex AI uses resources, accounts, and agents. The recommendations include:
- Using Bring Your Own Service Account (BYOSA) to replace the default service agent
- Applying the principle of least privilege (PoLP) to ensure the agent only has the permissions necessary to perform the task at hand
- Periodically reviewing the permissions associated with each project’s P4SA
- Avoiding the use of third-party models without careful provenance and origin analysis
- Implementing additional monitoring and auditing layers over the actions performed by AI agents in production
- Setting up alerts in Cloud Logging and Security Command Center to detect anomalous behavior
It’s worth noting that Google’s response to this discovery was considered responsive by Unit 42 itself. Google not only acknowledged the issue as valid but also collaborated with the researchers throughout the analysis and remediation process. This kind of partnership between independent security teams and major cloud providers is essential for the AI ecosystem to evolve more securely, especially now that AI agents are being adopted at scale by companies of all sizes. 🤝
What developers and security teams need to know now
Even with the fixes Google has implemented, this discovery serves as an important wake-up call for any team developing or operating AI agents on Google Cloud. The fact that a widely used platform like Vertex AI had this kind of flaw shows that security in AI agent-based environments can’t be treated as something the provider handles on its own. It’s a shared responsibility, and part of it falls directly on the teams building and maintaining these systems day to day.
One of the most important takeaways from this research is the need to review default permissions for all service components used in AI projects. More often than not, default configurations on cloud platforms are designed to ease adoption and reduce onboarding friction, but this can create situations where critical resources end up more exposed than they should be. Regularly auditing which permissions are active, which ones are actually needed, and what can be revoked without impacting system functionality should be a standard practice in every production project’s lifecycle.
As researcher Ofir Shaty himself pointed out, granting broad permissions to agents by default violates the principle of least privilege and represents a dangerous by design security flaw. Organizations should treat AI agent deployments with the same rigor applied to new code going into production: validate permission boundaries, restrict OAuth scopes to the bare minimum, review the integrity of sources, and conduct controlled security testing before putting anything live.
Another aspect that deserves attention is how external data consumed by AI agents is handled. Since indirect prompt injection was one of the vectors identified by Unit 42, it’s critical that teams implement sanitization and validation layers on the data agents process, especially when that data comes from external sources or end users. On top of that, monitoring agent behavior in real time — checking whether they’re making unexpected calls to internal endpoints or accessing resources outside their usual scope — can be the difference between catching an exploit early or discovering the problem far too late. 🔍
Why this discovery matters for the future of AI agents
The Vertex AI case illustrates a pattern that we’ll likely see repeat itself more and more as AI agents become central components of enterprise infrastructure. Unlike traditional applications, AI agents operate with a degree of autonomy that amplifies both their productive potential and the associated risks. An agent that has permission to read documents, access APIs, and execute actions in the cloud environment carries an attack surface that simply didn’t exist in the previous generation of software.
This research reinforces how important it is for cloud providers, developers, and security teams to work together to create governance frameworks specifically designed for AI agents. Applying the same security practices that already exist for microservices or containers isn’t enough. AI agents introduce new variables — like the ability to interpret and act on data autonomously — that demand equally new controls tailored to this reality.
The Unit 42 discovery is yet another reminder that artificial intelligence, no matter how powerful and useful it may be, brings with it a new layer of security challenges that we’re still learning to manage. And the sooner teams internalize that, the better prepared they’ll be for what’s coming next.
