Double Agents: Exposing Security Blind Spots in GCP Vertex AI
Unit 42 researchers discovered that malicious AI agents deployed in GCP Vertex AI could exploit default permission scoping to extract service agent credentials. This 'double agent' attack allows unauthorized access to consumer storage buckets, restricted Google internal infrastructure, and introduces risks of remote code execution via insecure pickle deserialization.
Authors: Unit 42
Source:
Palo Alto Networks
- urlgs://reasoning-engine-restricted/versioned_py/Dockerfile.zipInternal Google Cloud Storage bucket exposed within a discovered Dockerfile.zip.
- urlhxxp://metadata[.]google[.]internal/computeMetadata/v1/instance/?recursive=trueGCP metadata service endpoint queried by the malicious agent to extract service agent credentials.
- urlus-docker.pkg.dev/cloud-aiplatform-private/llm-extension/reasoning-engine-py310Restricted Google-owned Artifact Registry repository accessed using stolen credentials.
- urlus-docker.pkg.dev/cloud-aiplatform-private/reasoning-engineRestricted Google-owned Artifact Registry repository accessed using stolen credentials.
Key Takeaways
- Deployed AI agents in GCP Vertex AI could be weaponized to extract default P4SA service agent credentials via the metadata service.
- Compromised credentials granted unauthorized read access to consumer Google Cloud Storage buckets.
- Attackers could access restricted Google-owned Artifact Registry repositories and internal container images.
- Insecure serialization using Python pickle for agent code (code.pkl) introduces a risk of Remote Code Execution (RCE).
- Overly permissive default OAuth 2.0 scopes could potentially expose Google Workspace data if combined with IAM permissions.
Affected Systems
- GCP Vertex AI
- Google Cloud Platform (GCP)
- Google Cloud Storage
- Artifact Registry
Attack Chain
An attacker creates a malicious AI agent using the Google Cloud ADK and deploys it to the Vertex AI Agent Engine. Once deployed, the agent queries the GCP metadata service to extract the credentials of the default Per-Project, Per-Product Service Agent (P4SA). Using these overprivileged credentials, the attacker pivots to access consumer Google Cloud Storage buckets and restricted Google-owned Artifact Registry repositories. The attacker can also analyze deployment files like code.pkl to potentially achieve remote code execution via insecure deserialization.
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
The article does not provide specific detection rules, focusing instead on architectural misconfigurations, cloud posture management, and default permission risks.
Detection Engineering Assessment
EDR Visibility: None — The attack occurs entirely within the GCP control plane and managed serverless AI environments where traditional EDR cannot be deployed. Network Visibility: Low — Traffic between the AI agent, the metadata service, and cloud storage APIs is internal to Google Cloud's infrastructure. Detection Difficulty: Moderate — Requires baseline profiling of legitimate AI agent behavior to distinguish malicious API calls (like cross-project storage access) from normal operations.
Required Log Sources
- GCP Cloud Audit Logs
- GCP IAM Logs
- GCP VPC Flow Logs
Hunting Hypotheses
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Look for Vertex AI service agents (*@gcp-sa-aiplatform-re.iam.gserviceaccount.com) making unexpected storage.buckets.list or storage.objects.get API calls to consumer buckets. | GCP Cloud Audit Logs | Collection/Exfiltration | Medium |
| Monitor for unusual access patterns to the GCP metadata service (/computeMetadata/v1/instance/?recursive=true) originating from Vertex AI Agent Engine instances. | VPC Flow Logs / Metadata API logs | Credential Access | Medium |
Control Gaps
- Default overly permissive IAM roles for P4SA
- Broad default OAuth 2.0 scopes
- Insecure serialization (pickle) used by default for agent code
Key Behavioral Indicators
- Anomalous service agent API activity
- Unexpected cross-project resource access
- Excessive data read operations from storage buckets by AI service accounts
False Positive Assessment
- Low
Recommendations
Immediate Mitigation
- Implement Bring Your Own Service Account (BYOSA) for Vertex Agent Engine to enforce least privilege.
- Review and restrict IAM permissions for existing Vertex AI service agents.
Infrastructure Hardening
- Restrict OAuth 2.0 scopes to only those strictly necessary for the AI agent's function.
- Ensure cloud storage buckets have proper access controls and are not globally readable by default service agents.
User Protection
- N/A
Security Awareness
- Institutionalize AI security reviews as part of the deployment lifecycle.
- Treat AI agent deployment with the same rigor as new production code, validating permission boundaries and source integrity.
MITRE ATT&CK Mapping
- T1528 - Steal Application Access Token
- T1552.005 - Unsecured Credentials: Cloud Instance Metadata API
- T1078.004 - Valid Accounts: Cloud Accounts
- T1530 - Data from Cloud Storage
- T1068 - Exploitation for Privilege Escalation
Additional IOCs
- Domains:
metadata[.]google[.]internal- Internal GCP domain used to access instance metadata.us-docker[.]pkg[.]dev- GCP Artifact Registry domain hosting restricted images.
- Urls:
hxxp://metadata[.]google[.]internal/computeMetadata/v1/instance/?recursive=true- Endpoint used to extract GCP Service Agent credentials.
- File Paths:
Dockerfile.zip- Archive containing hardcoded information about internal Google Cloud projects and storage buckets.code.pkl- Python pickle file used for serializing agent code, presenting an insecure deserialization RCE risk.requirements.txt- Discovered in the tenant project storage bucket alongside agent deployment files.
- Other:
service-<PROJECT-ID>@gcp-sa-aiplatform-re.iam.gserviceaccount.com- Targeted GCP Service Account.