The Problem: Your Cloud AI Agent Has the Keys to Everything
Think of it like this: you hired a security guard for your building, and the guard company gave them a master key to every room, every filing cabinet, and every safe, even though they only need access to the lobby. Now imagine someone tricks that guard into working for them. That is not a hypothetical scenario. It is exactly what Palo Alto Networks researchers demonstrated is happening on one of the world's largest cloud platforms.
AI agents on cloud platforms are being given far too much access by default. When organizations deploy AI agents on Google Cloud's Vertex AI platform, those agents inherit a default service account that has access to an extraordinary range of services: Gmail, Google Drive, Calendar, Cloud Storage, and more. The agent does not need access to most of these services. It receives them simply because Google optimizes for easy setup, not for security.
This is not a theoretical risk. Palo Alto Networks Unit 42, one of the most respected threat intelligence teams in cybersecurity, published a detailed report showing exactly how these overprivileged agents can be turned into spies. Their researchers demonstrated multiple attack paths that allow an adversary to weaponize a legitimate AI agent into a "double agent" that secretly exfiltrates data, downloads proprietary software, and creates backdoors for persistent access.
The fundamental issue is a familiar one in cloud security: default configurations that prioritize convenience over protection. When every new AI agent receives broad permissions automatically, the blast radius of any compromise becomes enormous. A single exploited agent does not just leak one dataset; it can access your entire cloud project.
AI agents on cloud platforms receive default permissions that go far beyond what they need, creating a massive attack surface when those agents are compromised.
Why This Matters to You
If your organization runs AI agents on Google Cloud, or any major cloud platform, the default service account permissions likely give those agents access to far more than they need. An attacker who compromises one agent can pivot across your entire cloud project.
This is not limited to sophisticated nation-state attacks. The techniques Unit 42 demonstrated require no special tooling. Any attacker who can interact with the agent's input can trigger the full attack chain.
What Happened: Turning AI Agents Into Double Agents
Palo Alto Networks Unit 42 researchers demonstrated a complete attack chain against AI agents running on Google's Vertex AI platform. The attack exploits two fundamental weaknesses: overly permissive default credentials and the agent's ability to make internal cloud API calls. Here is what they found, step by step, explained in plain terms.
The researchers showed that a Vertex AI agent can be instructed (through prompt injection or malicious input) to query the Google Cloud metadata service. This is the internal directory that every cloud workload can contact to learn about itself and request credentials. Think of the metadata service as a receptionist's desk inside a building; any employee can walk up and ask for a temporary badge. The problem is that the badge they receive grants access to nearly everything.
The default service account attached to Vertex AI workloads carries what Google calls the "Editor" role. This role provides read and write access to almost every service in the Google Cloud project. The agent does not request this level of access; it simply inherits it by default. This is the cloud equivalent of giving every new hire a master key on their first day instead of issuing keys only for the rooms they actually need.
Beyond credential extraction, the researchers also identified that the Vertex AI environment contains serialized Python objects in a format called "pickle." Pickle files are inherently dangerous because opening one is like accepting a package from a stranger that automatically runs whatever code is packed inside. If an attacker can place or modify a pickle file in the agent's environment, they achieve remote code execution, the most severe category of vulnerability in cybersecurity.
Unit 42 researchers demonstrated how an AI agent on Vertex AI can be weaponized to extract credentials, access internal services, and create persistent backdoors.
The Attack Chain: Six Steps From Agent to Double Agent
The Unit 42 researchers broke down the full attack into six distinct stages. Each step builds on the previous one, escalating from initial access to full project compromise.
Agent Receives Malicious Input
Think of it like this: An attacker sends the AI agent a carefully crafted message or document that contains hidden instructions. This is similar to handing an employee a memo that looks like a routine request but contains secret orders written between the lines. The agent processes the entire input, including the hidden payload, and begins following the attacker's instructions alongside its normal tasks.
Result: The agent is now operating under the attacker's influence while appearing to function normally.
Metadata Service Query
Think of it like this: The compromised agent walks up to the building's internal directory and asks for the master key code. In technical terms, the agent sends an HTTP request to Google Cloud's metadata service endpoint, which responds with an OAuth access token. This token is the credential that grants access to other cloud services. The metadata service does not question why the agent needs the token; it simply provides one because the agent is a recognized workload in the project.
Result: The attacker now has a valid access token with the full permissions of the default service account.
Default Permissions Exploited
Think of it like this: The master key opens every door. The default Vertex AI service account has the "Editor" role, which grants read and write access to Gmail, Google Drive, Calendar, Cloud Storage, BigQuery, and dozens of other Google Cloud services. The agent was designed to work with perhaps one storage bucket. Instead, it can now access the organization's entire cloud footprint. This is the core of the "double agent" problem: the agent's legitimate identity provides cover for illegitimate access.
Result: A single compromised agent can read, modify, or delete data across the entire Google Cloud project.
Private Registry Access
Think of it like this: The attacker discovers the master key also opens the vault where the company stores its proprietary blueprints. Using the extracted credentials, the researchers were able to access Google's own private Artifact Registry and download proprietary container images. These images contain Google's internal software, configuration details, and potentially other secrets. For an attacker, this is a goldmine of intellectual property and a roadmap for finding additional vulnerabilities.
Result: Proprietary software and internal configurations are exfiltrated from private container registries.
Pickle Deserialization Attack
Think of it like this: Imagine opening a package from a stranger that automatically runs whatever instructions are packed inside, with no safety check. That is exactly what pickle files do. Pickle is a Python serialization format that executes arbitrary code when loaded. The researchers found pickle files present in the Vertex AI environment. If an attacker can modify or replace these files (which the overprivileged service account allows), they achieve remote code execution: the ability to run any command on the underlying server.
Result: Full remote code execution on the Vertex AI infrastructure through insecure deserialization.
Persistent Backdoor Established
Think of it like this: The attacker has made a copy of the master key and hidden it in a place only they know about. With remote code execution and broad service account permissions, the attacker can create new service account keys, establish persistent access tokens, or deploy additional compromised workloads. Even if the original attack vector is patched, the attacker retains access through these backdoors. The compromised agent continues operating normally, making detection extremely difficult.
Result: The attacker maintains long-term access to the cloud project even after the initial vulnerability is addressed.
Default Permissions vs. What the Agent Actually Needs
Read data from one specific Cloud Storage bucket
Write results to one specific output location
Call one external API for its specific task
Minimal, scoped access. If compromised, the blast radius is limited to one bucket and one API.
Gmail (read and send emails as the project)
Google Drive (access all shared documents)
Calendar (read schedules across the organization)
All Cloud Storage buckets in the project
BigQuery, Artifact Registry, Compute Engine, and more
Massively overprivileged. If compromised, the attacker has Editor access to the entire cloud project.
The gap between what an AI agent needs and what it receives by default is the core vulnerability. Attackers do not need to break in; they just need to convince the agent to use the access it already has.
Why This Is Worse Than a Traditional Cloud Breach
Traditional cloud security breaches typically require an attacker to find an exposed credential, exploit a misconfigured firewall, or compromise a user's account through phishing. These attacks leave traces in audit logs and often trigger security alerts. The "double agent" attack is fundamentally different because the AI agent is a legitimate, authorized workload. Every action the compromised agent takes appears in logs as normal agent behavior.
Consider the detection challenge: when a Vertex AI agent queries the metadata service for credentials, that is a normal operation. When it accesses Cloud Storage, that may be exactly what it was designed to do. When it makes API calls to other Google services, that could be part of its intended workflow. The attacker is not using stolen credentials or unauthorized access paths. They are directing the agent to use its own legitimate access in ways the agent's operators never intended.
This creates a security blind spot. Traditional monitoring tools that flag unauthorized access will not trigger on these attacks because the access is technically authorized. The agent has valid credentials, the permissions are real, and the API calls are legitimate. The only thing that is wrong is the intent behind them.
The pickle deserialization risk compounds the problem significantly. Pickle is a widely used Python serialization format, and many machine learning workflows depend on it. However, the Python documentation itself warns that pickle is not secure against maliciously constructed data. Loading a pickle file executes arbitrary code with the permissions of the process that loads it. In the context of Vertex AI, that means any code executed through pickle deserialization runs with the full permissions of the default service account. An attacker who can place a malicious pickle file in the right location gains complete control.
Impact Assessment
Unrestricted cloud project access, proprietary container image downloads from private registries, and potential remote code execution through insecure pickle deserialization.
The financial consequences of this type of breach are difficult to cap. An attacker with Editor-level access to a cloud project can exfiltrate customer data (triggering regulatory fines under GDPR, CCPA, and similar frameworks), steal intellectual property from private registries, manipulate data in production databases, and establish persistent access that survives incident response efforts. The cost of a breach through an AI agent double attack could easily reach millions of dollars when factoring in regulatory penalties, forensic investigation, customer notification, and reputational damage.
What You Can Do: Six Steps to Lock Down Your Cloud AI Agents
The good news is that every vulnerability Unit 42 identified can be mitigated with changes to configuration and operational practices. None of these fixes require new technology. They require discipline and a shift in mindset: stop accepting default permissions, and start treating every AI agent as a potential attack surface. Here are six practical steps your team can implement immediately.
Effective defense starts with replacing default service accounts and restricting what each AI agent can access to only what it needs for its specific task.
Use your own service accounts, not platform defaults
Think of it like this: bring your own house key instead of accepting the master key the building manager offers you. The default Vertex AI service account has the Editor role, which grants access to nearly everything in your project. Instead, create a custom service account for each AI agent with only the specific permissions that agent needs.
In Google Cloud, this means creating a new service account in IAM, assigning it the minimum required roles (for example, "Storage Object Viewer" for one specific bucket instead of "Editor" for the whole project), and attaching it to the Vertex AI workload. This single change eliminates the broad default access that makes the double agent attack possible.
Restrict what the AI agent can access to only what it needs
Apply the principle of least privilege rigorously. Before deploying any AI agent, document exactly which cloud resources it needs to read from, write to, and interact with. Then configure its service account to allow only those specific operations on those specific resources.
Use IAM Conditions to add further restrictions based on time of day, source IP range, or resource tags. Use VPC Service Controls to create a security perimeter around the resources the agent should access, preventing any data from leaving that perimeter even if the agent's credentials are compromised.
Lock down the internal directory (metadata service)
The metadata service is the internal endpoint that provides credentials to workloads. If the AI agent does not need to dynamically request credentials (and most do not), restrict or block its access to the metadata service entirely. This prevents the first step of the attack chain: credential extraction.
On Google Cloud, you can use network policies to block outbound requests to the metadata IP address (169.254.169.254) from AI agent workloads. Alternatively, use Workload Identity Federation to provide credentials through a more controlled channel that supports fine-grained access policies and audit logging.
Audit for dangerous file formats that could run hidden code
Scan your AI agent environments for pickle files and other serialization formats that execute code on load. Pickle files are standard in machine learning workflows, but they are inherently unsafe. Every pickle file is a potential code execution vector.
Where possible, migrate to safer serialization formats such as SafeTensors, JSON, or Protocol Buffers. If pickle files are unavoidable, implement integrity verification (cryptographic hashes) to ensure they have not been tampered with. Run pickle loading in isolated sandboxes with no network access and restricted file system permissions.
Require human security review before deploying any AI agent
No AI agent should go to production without a security review that covers its service account permissions, network access, input sources, and data flow. This review should be performed by someone who understands cloud IAM, not just the team that built the agent.
Create a deployment checklist that includes: verification that a custom (non-default) service account is attached, confirmation that permissions follow least privilege, validation that metadata service access is restricted, and a review of all serialization formats used in the agent's workflow. Treat AI agent deployment with the same rigor as deploying a new internet-facing application.
Regularly check what your cloud AI agents actually have access to
Permissions drift over time. Service accounts accumulate additional roles as teams add features. What started as a tightly scoped agent may gradually gain access to resources it was never meant to touch.
Schedule monthly audits of all service accounts associated with AI agent workloads. Use Google Cloud's IAM Recommender to identify permissions that are granted but never used, and remove them. Set up alerts for any changes to AI agent service account permissions so your security team is notified immediately when access is expanded.
The Bottom Line
Cloud platforms optimize for easy setup, not for security. When Google Vertex AI assigns a default service account with Editor-level access to every AI agent, it is prioritizing developer convenience over your organization's protection. Unit 42's research makes this tradeoff painfully visible: the same default configuration that lets a developer get an agent running in minutes also lets an attacker turn that agent into a spy that can access your emails, your documents, your databases, and your proprietary software.
The core lesson is straightforward: never accept default permissions. Every AI agent should have the minimum access needed to do its job, nothing more. Custom service accounts, restricted metadata access, safe serialization formats, and mandatory security reviews are not optional best practices. They are prerequisites for responsible AI deployment in the cloud.
This is not a Google-specific problem. Every major cloud platform has similar default permission patterns that prioritize ease of use. If your organization runs AI agents on AWS, Azure, or any other provider, audit those agents with the same scrutiny. The double agent attack pattern applies anywhere an AI workload inherits overprivileged default credentials.
This article is part of our incident analysis newsletter series. Subscribe to receive complete analyses with timeline tables, risk matrices, governance checklists, and actionable recommendations.
