Palo Alto flags Vertex AI permission risks
Palo Alto Networks’ Unit 42 warned that Google Cloud’s Vertex AI agents can become risky when permissions are too broad, enabling unintended or unsafe agent behaviour. The reporting frames the issue as a classic identity-governance problem—delegated authority without sufficient policy boundaries or visibility. Recommended detection steps include dashboards for agent permissions, first-seen integrations, and correlation of IAM changes with downstream data access ( | ).
An artificial intelligence agent is software that can call tools, read data, and take actions on its own. Palo Alto Networks’ Unit 42 said agents deployed on Google Cloud’s Vertex AI can become dangerous when they inherit permissions that are broader than their job requires. (unit42.paloaltonetworks.com) Google markets Vertex AI Agent Engine as a service for deploying, managing, and scaling production agents. In Google’s own documentation, deployed agents can run either with a Google-managed service account or a custom service account, and they can access whatever resources that identity is allowed to reach. (docs.cloud.google.com | docs.cloud.google.com) A service account is a machine identity, like an employee badge for software instead of a person. Unit 42 said the risk appears when that badge opens too many doors, because a compromised or misconfigured agent can read data, change infrastructure, or create persistence using trusted cloud permissions. (unit42.paloaltonetworks.com) In research published March 31, 2026, Unit 42 said it deployed an agent with Google Cloud’s Application Development Kit and found that the per-project service agent tied to the deployment had excessive permissions by default. The researchers said they obtained privileged access to data in a consumer project and to restricted images and source code in a producer project inside Google’s infrastructure. (unit42.paloaltonetworks.com) Google’s documentation now spells out that the AI Platform Reasoning Engine Service Agent runs deployed agents by default in some setups and that administrators can inspect its roles in Identity and Access Management. Google also added newer guidance for “agent identity,” a per-agent identity feature now labeled preview and described as a least-privilege approach. (docs.cloud.google.com | docs.cloud.google.com) That distinction matters because Google’s separate Vertex AI guidance says custom service accounts are the way to give jobs or models narrower, task-specific access. The same page says Google-managed service agents can be too coarse when teams want fine-grained control over which buckets, tables, or services a workload can touch. (docs.cloud.google.com) Unit 42 said it disclosed the findings to Google before publication, and several reports citing the company said Google updated its documentation in response. The published materials reviewed here do not show Google describing the issue as a product vulnerability with a software patch; the visible change is documentation that clarifies how identities and permissions work. (unit42.paloaltonetworks.com | techintelpro.com | cxotoday.com) Google’s agent identity page also says the feature is covered by pre-general-availability terms and recommends using it in test environments only. For production teams deploying agents today, that leaves the older identity-and-access-management work of auditing service accounts, trimming roles, and tracking what each agent can actually reach. (docs.cloud.google.com | docs.cloud.google.com) The core issue is not that an agent “goes rogue” by itself. It is that a trusted automation system can do exactly what its credentials allow, and in cloud systems, that can be much more than the developer intended. (unit42.paloaltonetworks.com | docs.cloud.google.com)
