Vertex AI Double Agents: When Service-Agent Defaults Become an Agentic Cloud Boundary
Unit 42 showed how a deployed Vertex AI Agent Engine workload (Google Cloud's managed runtime for AI agents) 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
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.
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.
Authenticate Vertex AI runtime calls with a dedicated service identity, short-lived audience-bound token, route binding, and verifiable token provenance. This proves which managed identity is calling; M-009 and H-018 controls separately limit mission scope and decide whether that identity may access the requested GCP resource.
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.
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.
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.
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.
Define a machine-checkable authority envelope for the Vertex AI agent across data classes, projects, registries, effect types, and mission scope. The extracted P4SA token bypassed the tool layer, so this envelope must be bound to the deployed identity and supplied to downstream authorization; it exposes over-broad authority but does not itself deny GCP API use.
Correlate metadata-token issuance and use with the Vertex AI service agent, token audience and scope, agent-tool request, downstream resource, project boundary, and access fan-out. Authentication can succeed while the valid non-human identity is being abused; unusual GCS listing, restricted Artifact Registry reads, deployment-file enumeration, or cross-project access should therefore be evaluated against the service agent's signed policy and normal resource graph.
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.