The rapid adoption of powerful artificial intelligence platforms has introduced a new class of security challenges, where seemingly benign default settings can conceal critical vulnerabilities. Recent analysis of Google’s Vertex AI platform reveals that its out-of-the-box configurations create significant pathways for privilege escalation, allowing attackers with minimal access to seize control of highly sensitive data and powerful cloud identities. The core of the issue lies with Google-managed identities known as Service Agents, which are automatically assigned broad, project-level permissions. This design choice, which Google has classified as “working as intended,” establishes a classic “confused deputy” scenario. In this situation, a low-privileged user can deceive a more powerful service into executing unauthorized commands on their behalf, effectively turning a minor foothold into a major security breach. This inherent risk transforms standard deployment practices into a potential minefield for unprepared organizations.
Exploiting the Confused Deputy Vulnerability
One of the primary attack vectors targets the Vertex AI Agent Engine, a component designed to enhance large language models (LLMs) with custom tools. An attacker only needs the aiplatform.reasoningEngines.update permission—a right that might be granted for development or testing purposes—to initiate the exploit. The attack begins by injecting malicious code, such as a reverse shell, disguised as a legitimate Python tool. This tainted tool lies dormant until an unsuspecting user or automated process makes an LLM query that triggers its execution. Once activated, the malicious code runs with the permissions of the underlying service, granting the attacker remote code execution (RCE) on the instance. From this compromised position, the attacker can query the instance metadata to steal the access token for the associated Reasoning Engine Service Agent. This token is the ultimate prize, as it unlocks extensive permissions to read sensitive LLM memories, private chat logs, and confidential data stored across Google Cloud Storage (GCS) buckets, all from a single, seemingly minor permission.
A second, and perhaps more alarming, exploitation path exists within Ray on Vertex AI, a framework for scaling AI workloads. This vector dramatically lowers the barrier to entry, requiring an attacker to possess only the aiplatform.persistentResources.get/list permission, which is typically included in the basic, read-only Viewer role. The exploit is remarkably straightforward: the attacker simply navigates to the GCP Console and accesses the “Head node interactive shell” link. This single action bypasses their restricted role and instantly grants them a root shell on the cluster’s head node. With root access, the attacker can effortlessly extract the Custom Code Service Agent’s token from the instance metadata. This credential provides sweeping read and write access to critical data repositories, including project-wide Google Cloud Storage and BigQuery datasets. This attack demonstrates how a role intended for observation can be weaponized to achieve full data control, highlighting a critical flaw in the platform’s default security posture.
Proactive Mitigation and a Shift in Mindset
Both of these attack chains underscore a dangerous pattern: they start with seemingly harmless, low-level permissions and culminate in the theft of highly privileged credentials from easily accessible instance metadata. To counter these threats, organizations must move beyond accepting default configurations and adopt a proactive security stance. The most critical step is to revoke unnecessary default permissions from Service Agents by implementing custom Identity and Access Management (IAM) roles. Adhering to the principle of least privilege ensures that these powerful identities only have the specific permissions required for their tasks. Furthermore, direct mitigation for the identified vectors is essential. This includes disabling interactive head node shell access on Ray on Vertex AI clusters and enforcing rigorous code validation and security scanning for any custom tool code before it is deployed to the Vertex AI Agent Engine. Continuous monitoring using tools like Google’s Security Command Center is also crucial for detecting tell-tale signs of an attack, such as RCE attempts or unauthorized metadata access.
Ultimately, the findings surrounding Vertex AI’s default settings necessitate a fundamental shift in how enterprises approach cloud AI security. Instead of viewing these configurations as standard, secure-by-default features, security teams must treat them as inherent risks that require immediate and thorough assessment. This involves a move away from implicit trust in platform defaults toward an explicit, zero-trust security model. The incidents highlighted the importance of a defense-in-depth strategy where security is not an afterthought but a core component of the AI development lifecycle. By hardening IAM policies, implementing strict code review processes, and maintaining vigilant monitoring, organizations can transform a high-risk environment into a more resilient and secure AI infrastructure, ensuring that the convenience of managed services does not come at the cost of data integrity and confidentiality.