Security researchers found that default behaviors in Vertex AI’s identity and access model can let low-privileged users escalate themselves into powerful Service Agent roles — effectively turning those managed identities into “double agents.”
Service Agents are special managed accounts that Google Cloud uses to run internal processes for Vertex AI; by default they often hold broad project permissions.
The result: attackers with minimal roles can pivot into these higher-privileged identities and use them to access sensitive data and operations far beyond their original limits.
Two Distinct Attack Vectors
Research identifies two technical vectors that facilitate this privilege escalation:
1. Vertex AI Agent Engine Tool Injection
- Attackers with just the
aiplatform.reasoningEngines.updatepermission — possibly part of a basic Vertex AI role — can update an existing reasoning engine with malicious code, such as a Python reverse shell. - When that code executes on the compute instance, it provides remote code execution (RCE) on the underlying machine.
- From there, the attacker queries the instance metadata service to obtain the Reasoning Engine Service Agent’s token (e.g.,
service-<project_id>@gcp-sa-aiplatform-re.iam.gserviceaccount.com). - That token inherits permissions like:
- Vertex AI session and memory access
- Reading storage buckets
- Logging and resource-management reads
This is essentially a confused-deputy attack where an innocuous update operation is abused to gain broad privileges.
2. Ray on Vertex AI — Viewer to Root
- In the Ray on Vertex AI feature, when a cluster is deployed, the Custom Code Service Agent is automatically attached to the ray head node.
- XM Cyber found that users with only read-only permissions — typically those in the Vertex AI Viewer role (e.g.,
aiplatform.persistentResources.getand…list) — can open a head-node interactive shell via the GCP Console. - Although those permissions should be limited, the console UI still exposes a link that leads to a root shell on the node.
- With root access, the attacker then fetches the Custom Code Service Agent’s token from metadata.
- That token, while scoped, still includes:
- Full control of Cloud Storage
- BigQuery access
- Pub/Sub
- Broad cloud-platform read access
This yields a viewer-to-powerful-agent escalation that should not occur under least-privilege principles.
What Makes This a “Double Agent” Bug
The key design flaw isn’t just privilege escalation — it’s how managed identity tokens are automatically tied to compute instances with broad permissions, and how the platform exposes unexpected access paths (like head-node shells) to users who shouldn’t have them.
Because these service agents are “invisible” and rarely audited by teams, misuse blends into normal operations, making detection hard.
Security Impacts
An attacker exploiting either vector can:
- Read sensitive Vertex AI data like LLM memories and chat logs.
- Access and modify cloud storage buckets.
- Interact with BigQuery datasets, including read/write operations.
- Use broader services like Pub/Sub, depending on token scope.
This can lead to data leakage, insider-style access, or lateral movement within a cloud project.
Mitigations and Recommendations
Because Google currently states these behaviors are “working as intended” (i.e., defaults remain unchanged), security analysts recommend immediate mitigations:
- Restrict sensitive IAM permissions (e.g., deny
aiplatform.reasoningEngines.updatewhere not needed). - Review and limit Vertex AI Viewer role scopes, especially around persistent resources.
- Disable unmanaged head-node shell access for Ray clusters where possible.
- Log and monitor metadata service queries and token usages as suspicious events.
Experts also advise auditing managed identity roles and enforcing least-privilege IAM policies across AI services.
