Vertex AI 'Double Agents': over-privileged service agents as a cloud escalation path

What is this?

On 31 March 2026, Palo Alto Networks Unit 42 disclosed a security “blind spot” in Google Cloud Vertex AI that lets a misconfigured or compromised AI agent be turned into what researcher Ofir Shaty calls a “double agent” — an agent that appears to do its job while quietly exfiltrating data, reaching internal resources and pivoting across a cloud project. There is no novel model exploit here. The finding is an identity and permission-scoping problem: the service identity provisioned for a deployed agent carries far more authority than the agent’s task needs, and that authority is reachable from inside the agent’s own execution context.

This matters because it is a class of failure, not a single bug. The same pattern — an AI service agent inheriting platform-level credentials without least-privilege scoping — recurs wherever agents are deployed as first-class cloud workloads. Google has since updated its documentation and changed its guidance (see Status), which is why this can be discussed openly.

How it works

When you build an agent with Vertex AI’s Agent Development Kit (ADK) and deploy it through Agent Engine, Google provisions a Per-Project, Per-Product Service Agent (P4SA) for it. Unit 42 found that this P4SA had excessive permissions granted by default, and — crucially — that those credentials are reachable from within the running agent:

• The metadata service hands out the credential. After deployment, any call to the agent triggers a request to Google’s internal metadata service, which exposes the service agent’s credentials along with the hosting GCP project, the agent’s identity and the machine’s scopes. This is the same cloud-native pattern behind classic IMDS credential theft — see MCP cloud takeover via IMDS — applied to an agent runtime.
• The credential escapes its sandbox. Using the harvested credential, the researchers jumped from the agent’s execution context into the customer project, undermining the isolation guarantee and gaining unrestricted read access to every Google Cloud Storage bucket in that project.
• It also reached Google’s own tenant. Because Agent Engine runs inside a Google-managed tenant project, the same credential surfaced details of the platform’s internal infrastructure and — more notably — granted read access to restricted Artifact Registry repositories, including container images that make up the Vertex AI Reasoning Engine. Unit 42 notes this exposes proprietary code and gives an attacker a map of the internal software supply chain.

The trigger condition is an agent that processes untrusted input or runs attacker-influenced code — for example via indirect prompt injection or a malicious serialized payload. The damage comes from the standing, over-scoped credential sitting one metadata call away.

Why it matters

Agents are increasingly deployed as ordinary cloud workloads, and they inherit the cloud’s oldest weakness: over-broad default service identities. The lesson Unit 42 draws is blunt — granting agents broad permissions by default violates least privilege and is “a dangerous security flaw by design.”

The blast radius is what makes this a med-to-serious concern rather than a curiosity. A single read-everything credential turns a helpful agent into an insider threat: data exfiltration from any bucket, reconnaissance of internal infrastructure, and access to private images that can seed the next attack. The honest bound on severity is that exploitation still requires the agent to be misconfigured or compromised first — this is not a remote, unauthenticated takeover. But in agent deployments, “compromised by injected input” is not a remote scenario; it is the expected one. That is the same coupling described by the lethal trifecta: private-data access plus untrusted input plus an exfiltration path.

Defenses

The mitigations are squarely in the cloud-IAM and deployment-hygiene tradition, and they generalize beyond Vertex AI:

• Replace the default service agent. Google’s recommended fix is Bring Your Own Service Account (BYOSA) in place of the default P4SA, scoped to the principle of least privilege so the agent holds only the permissions its task requires. If your platform provisions a default identity, treat it as untrusted until you have scoped it.
• Restrict OAuth scopes to least privilege. Shaty’s guidance is explicit: validate permission boundaries and cut OAuth scopes to the minimum. A standing read-all-buckets grant is the precondition the whole chain depends on.
• Treat agent deployment as production code. Review source integrity, validate boundaries, and run controlled security testing before rollout — not after the agent is live and reachable.
• Lock down the metadata path. Where the platform allows it, limit which workloads can reach the metadata service and what it returns; the credential that never reaches the agent runtime cannot be stolen from it.
• Segment the project. Don’t let one agent’s blast radius be “the entire project.” Use separate projects, VPC Service Controls and per-resource IAM so a leaked credential reads one bucket, not all of them.
• Monitor agent-initiated calls to cloud APIs. Sudden bucket enumeration or registry pulls from an agent identity is a strong signal that the credential has been turned against you.

Status

Item	Detail
Disclosed by	Palo Alto Networks Unit 42 (researcher Ofir Shaty)
Date	31 March 2026
Affected surface	Vertex AI Agent Engine + ADK; default Per-Project, Per-Product Service Agent (P4SA)
Mechanism	Metadata service exposes over-scoped service-agent credential to the agent runtime
Impact	Read all GCS buckets in the customer project; access tenant infrastructure details and restricted Artifact Registry images
Vendor response	Google updated access-control documentation; recommends BYOSA + principle of least privilege
Nature	Permission-scoping / identity flaw, not a novel model exploit

This is a defensive, design-level write-up: no exploit payloads, no actionable attack chain. The durable takeaway is the one that long predates LLMs and now applies to them — an agent is only as safe as the identity it runs under, and a default credential that can read everything is a breach waiting for a trigger.