Article Published: Apr 25, 2026

Vertex AI Double Agents: When Service-Agent Defaults Become an Agentic Cloud Boundary

Unit 42 showed how a deployed Vertex AI Agent Engine workload could become a "double agent" by extracting Google-managed service-agent credentials from its runtime and using those permissions to read customer project storage, inspect restricted Google-managed artifacts, and expose sensitive deployment files. Google updated documentation and recommends Bring Your Own Service Account (BYOSA), but the larger lesson is broader: an AI agent's cloud identity, runtime scopes, deployment artifacts, and network reach are one security boundary.

Credential ExposureData ExfiltrationIdentity & AccessVertex AICloud IAM
8 applicable AIDEFEND defenses
Source: Double Agents: Exposing Security Blind Spots in GCP Vertex AI 
By Ofir Shaty · Original article: Mar 31, 2026

Threat Analysis

  • The agent runtime inherited a powerful managed identity. Unit 42 focused on Vertex AI Agent Engine's P4SA, a Google-managed service account used by Vertex AI to access service resources.
  • Credential exposure turned agent code into cloud access. A malicious agent tool queried Google's metadata service, extracted the service-agent token, and used that identity outside the normal agent flow.
  • The first pivot crossed into the customer project. With the token, the researchers reported read access to Google Cloud Storage buckets in the consumer project.
  • The second pivot exposed provider-side artifacts. The same identity could read restricted Google-owned Artifact Registry repositories and download internal Vertex AI Reasoning Engine images. Google said separate controls blocked production image modification.
  • The tenant project added deployment leakage. Files such as Dockerfile.zip, code.pkl, and requirements.txt revealed internal paths and implementation details. Pickle-based serialization also raised a code-execution concern if the file could be manipulated.
  • The mitigation is not just one patch. Google revised documentation and pointed users toward BYOSA; defenders still need least-privilege identities, scoped OAuth access, artifact controls, segmentation, and monitoring.

Applicable AIDEFEND Defenses (8)

AID-M-005.002
Configuration Baseline Definition & Posture SLOs (Service Level Objectives)
Very High
This is the primary control because the failure mode is a default platform configuration with more access than most users would expect. Secure baselines for Vertex AI Agent Engine should define approved service-account patterns, default-disabled broad storage and Artifact Registry access, allowed OAuth scopes, metadata-service reachability, and a BYOSA baseline for production agents.
AID-H-004.002
Service & API Authentication
Very High
The attack path depends on a service-agent token being useful beyond the narrow work the agent was supposed to perform. Service authentication controls should favor dedicated service accounts, short-lived credentials, explicit audience and scope binding, token provenance checks, and rapid revocation when a managed AI runtime identity is exposed.
AID-M-009.003
Agent Identity, Delegation Lineage & Runtime Authorization
Very High
A Vertex AI agent should not appear in logs only as a broad Google-managed service identity. Defenders need to know which agent instance acted, which user or project authorized it, which delegated scope it received, and whether the action still matched the approved mission. That directly addresses the consumer, tenant, and producer-project confusion in the research.
AID-H-019.004
Intent-Based Dynamic Capability Scoping
High
A deployed agent that only needs to answer a narrow workflow should not inherit broad project storage reads, Artifact Registry discovery, or latent Workspace API reach. Per-session and per-intent capability envelopes keep a malicious tool function from expanding the runtime's effective permissions just because the underlying managed identity can reach more services.
AID-I-002.001
Internal AI Network Segmentation
High
The metadata service, tenant project storage, customer buckets, and provider artifact registries should not all be reachable as one flat execution neighborhood. Segmentation and microsegmentation around agent backends, artifact stores, and service-control paths reduce lateral movement when an agent runtime or token is compromised.
AID-H-003.002
CI/CD Release Gating, Model Artifact Signing & Secure Distribution
High
The exposed restricted images, deployment package, and code.pkl file make artifact governance part of the lesson. Agent packages, container images, and runtime bundles should be promoted only from approved registries with signatures, immutable digests, provenance records, and checks that reject unsafe serialization or unexpected dependencies.
AID-D-005.002
Security Monitoring & Alerting for AI
Medium
This attack path leaves operational signals: metadata-token requests from agent tools, service-agent access outside expected services, unusual GCS listing, restricted Artifact Registry reads, and deployment-file enumeration. AI-aware monitoring should alert on those patterns before the stolen identity becomes a quiet cross-project access path.
AID-D-011.001
Agent Behavioral Analytics & Anomaly Detection
Medium
A "double agent" is, operationally, a deployed agent whose behavior no longer matches its declared purpose. Behavioral attestation can baseline expected tool calls, storage access, network destinations, and credential use for each agent class, then flag agents that start harvesting tokens or enumerating infrastructure.

What Defenders Should Do Now

  • Inventory every Vertex AI Agent Engine deployment and record its runtime identity, P4SA, BYOSA status, OAuth scopes, staging bucket, Artifact Registry access, and owner.
  • Move production agents to dedicated BYOSA identities where available. Give each identity only the storage buckets, model endpoints, registries, and APIs needed for that specific agent workflow.
  • Block or tightly control metadata-service token access from agent tools. Treat any agent function that reads instance metadata, environment credentials, or cloud tokens as a high-risk action that needs review and logging.
  • Review GCS and Artifact Registry permissions granted to Vertex AI-related service accounts. Remove broad list/read permissions that are not required, especially across tenant, build, staging, and production boundaries.
  • Promote agent code and container artifacts through signed release gates. Prefer non-executable or safer serialization formats where possible, and reject unexpected pickle-based execution paths in production deployment flows.
  • Add detections for service-agent anomalies: unusual bucket enumeration, reads from restricted registries, metadata-token access, Workspace API attempts, and actions from managed identities outside their normal project or service path.

1 additional consideration

Managed AI service identity transparency

Beyond the techniques mapped above, teams using managed AI agent platforms should also require clearer provider evidence about hidden service identities, non-editable OAuth scopes, tenant-project resources, producer-project dependencies, and which permissions are customer-controlled versus provider-controlled.
Recommendation: Ask cloud providers for machine-readable service-agent manifests, effective-permission reports, documented metadata-service behavior, and assurance that customer service agents cannot read or modify provider production artifacts beyond the documented deployment path.

Conclusion

The Vertex AI case is not just about one cloud permission surprise. It shows how an AI agent platform can turn managed identity, runtime packaging, metadata services, and provider-side artifacts into one connected trust boundary. AIDEFEND  maps strongly to secure baselines, service authentication, agent identity governance, capability scoping, segmentation, artifact release gates, and monitoring. The practical goal is simple: a deployed agent should have a name, a narrow job, a narrow identity, a narrow network path, and evidence for every place it is allowed to reach.