Vertex AI under threat a poorly configured agent can become a double agent and steal credentials in the cloud

A team of security researchers has exposed a blind area in Vertex AI of Google Cloud that deserves the immediate attention of any team that is deploying artificial intelligence agents in the cloud. The problem is not an anecdotal failure: it allows a misconfigured or compromised agent to act as a "double agent," while retaining its legitimate appearance as it extracts credentials, data and attack vectors within the cloud environment.

The find, published by specialists of Unit 42 of Palo Alto Networks, points to the permissions model that Google applies to agents deployed with Vertex AI, in particular to the so-called "Per-Project, Per-Product Service Agent" (P4SA) service. By default, this agent receives quite extensive permissions, which opens a dangerous door: if an attacker manages to run code that consults the Google Cloud metadata service from the agent's context, he can get associated credentials and, from there, move laterally within the project.

Technically, by launching an agent with Vertex AI's Agent Engine, any call that the agent makes to the metadata service can reveal not only the service's token, but also information from the GCP project that houses the agent, the identity of the agent itself and the host's scopes where it is running. With these credentials, the researchers managed to jump from the isolated context of the agent to the resources of the client project. In practice, that meant unrestricted reading access to data stored in Google Cloud Storage within that project, making a tool of help an insider-type risk.

The exposure was not limited to the client's project. Since the Agent Engine can operate within Google-managed tenant projects, credentials also showed metadata and references to buckets that are part of the platform's internal infrastructure. Although in some cases such credentials did not have permission to download these buckets directly, they did allow for the discovery of protected routes and repositories.

A particularly worrying consequence was the possibility of access to private artifact registry devices that had been recorded in the logs during the deployment of the Agent Engine. With that visibility, an attacker could download container images that are part of the core of the Vertex AI reasoning engine, and until they get access to the content of other private repositories. Access to this proprietary code not only involves loss of intellectual property, but also makes it easier for an attacker to map the platform's software supply chain and locate obsolete or vulnerable images for later exploitation.

Google has reacted by updating its official documentation to explain more clearly how Vertex AI uses accounts, resources and agents, and indicates measures that customers should apply. Recommendations include replacing the default agent with a self-service account (Bring Your Own Service Account, BYOSA) and strictly applying the principle of lower privilege so that the agent has only the necessary capabilities for his or her task. Details on agents and Engine can be found in the Vertex AI documentation, and the IAM good practice guide provides the guidelines for limiting permissions and scopes: Vertex AI - Agents and Good IAM practices in Google Cloud.

From an operational security perspective, this case offers clear lessons. The first is that it is not enough to treat an IA agent as a harmless object: its deployment must be subject to the same controls as any new microservice or application in production. Limit OAuth scopes, audit interactions with metadata, review the permissions assigned to service accounts and test the agent's behavior under controlled conditions are indispensable steps before taking out an agent to production.

Another practical recommendation is to make use of service accounts managed by the team itself, configured with minimum permissions and key rotation; this avoids relying on agents with too wide privileges by default. It is also advisable to monitor and alert about unusual uses of methadata and mass reading blocks in Cloud Storage or access to private repositories that are not justified.

This incident also underlines the importance of protecting the software supply chain in cloud environments. Access to container images and private artifacts can serve an attacker as a plane to reproduce the environment, search for faults and prepare deeper attacks. Artifact Registry documentation and stricter access controls can mitigate some of this risk: Artifact Registry - documentation.

In short, the appearance of this vector shows that the security in the A-era in the cloud is not only a matter of models and data: it also depends on how identities, permissions and deployments are managed. The researchers' recommendations can be summarized in a practical advice for security and operations teams: treat each agent as if it were new production infrastructure, audit their permits and remove any privileges that are not necessary.

If you want to deepen the technical report and the original research, the analysis of the experts is available on the web of Unit 42, and it's a good idea to review Google Cloud's official documentation on agents and identity management to apply the recommended mitigation.