Unit 42 reported that a deployed Vertex AI Agent Engine workload could become a 'double agent': agent tool code queried the instance metadata service, extracted the Google-managed per-product service account (P4SA) token bound to the runtime, and used that identity directly against Google Cloud APIs, outside the normal agent flow. With that token the researchers reported read access to Google Cloud Storage buckets in the consumer project, and read access to restricted Google-owned Artifact Registry repositories including internal Vertex AI Reasoning Engine images; Google stated that separate controls blocked modification of production images. Tenant-project deployment files such as Dockerfile.zip, code.pkl and requirements.txt were enumerable and revealed internal paths and implementation details, with the pickle-based serialization raising a code-execution concern if such a file could be manipulated. Google revised its documentation and pointed customers toward Bring Your Own Service Account.
ASSESSED SYSTEM
A Vertex AI Agent Engine deployment running under the platform's default identity configuration as Unit 42 tested it (research published 2026-03-31): the managed agent runtime, the Google-managed per-product service account (P4SA) bound to it, the instance metadata service reachable from agent tool code, the tenant-project deployment artifacts staged for that runtime, and the customer-project and provider-side resources that identity could reach.
OUT OF SCOPE
Vertex AI Agent Engine after Google's documentation revision and its Bring Your Own Service Account (BYOSA) guidance; deployments already running under BYOSA with least-privilege scopes; Google's production image-modification controls, which Google stated blocked modification and which are treated here as a control that held; other Google Cloud services; and the customer agent's own model, prompts and task quality, which this incident does not implicate.
Architecture: Agentic / MCP System (decision tree Q2) — Q1 is NO — a single deployed agent workload is assessed, with no inter-agent coordination described. Q2 is YES: Vertex AI Agent Engine is a managed runtime for agents that execute multi-step workflows and invoke tools without per-action human approval, and the incident turns on exactly that property — 'a malicious agent tool queried Google's metadata service, extracted the service-agent token, and used that identity outside the normal agent flow'. Agentic intra-axis weights apply. Tier 3: Tier 3 Internal: the assessed unit is a customer-deployed agent workload running inside that organisation's cloud project and invoked by controlled users, which matches the Tier 3 workflow-automation examples; the cross-tenant and provider-side reach the research demonstrates is an amplification of impact and is captured in Cascade Potential rather than by raising the tier, and a Vertex agent fronting a public product or handling regulated data would be classified higher on its own facts.
Documented attack or failure path
- Agent tool code running inside the Vertex AI Agent Engine runtime queries the instance metadata service, which is reachable from the execution environment.
- The metadata service returns the Google-managed service-agent (P4SA) token bound to that runtime.
- The token is used directly against Google Cloud APIs, outside the agent flow, so whatever constraints the tool layer imposes no longer apply to the actions taken.
- First pivot: read access to Google Cloud Storage buckets in the consumer (customer) project.
- Second pivot: read access to restricted Google-owned Artifact Registry repositories, including download of internal Vertex AI Reasoning Engine images.
- Tenant-project deployment artifacts (Dockerfile.zip, code.pkl, requirements.txt) are enumerated, exposing internal paths and implementation detail, with pickle deserialization a latent code-execution path if those artifacts could be modified.
Observed controls and bounded outcomes
Positive credit is given only where the record directly demonstrates a control operating. Recommended or merely presumed controls receive no positive scoring credit.
- Google reported that separate controls blocked modification of production images: the provider-side write boundary held even though the read boundary did not, and no capability to alter provider artifacts was demonstrated.
- All demonstrated cross-boundary access was read-only; the researchers report no write, delete or credential-minting action succeeding against customer or provider resources.
- Authentication itself behaved correctly — the token was valid, issued to a documented identity and accepted as that identity; the failure is authorization breadth and the absence of instance-level binding, not broken authentication.
- Cloud-native audit logging did record the API calls made with the token (principal, resource and time), which is why Tr-3 sits at 0.50 rather than lower; what it could not do is attribute them to an agent instance or a delegation chain.
- A supported least-privilege path existed and Google directed customers to it: Bring Your Own Service Account, alongside a documentation revision.
Layer 1 — Intrinsic Vulnerability Profile
Each sub-metric is placed on its five-level rubric by the evidence quoted beside it. Missing applicable evidence remains unknown. The displayed midpoint and interval are scenario values, not inferred control performance.
| Sub-metric | Score | Rubric basis | Evidence |
|---|---|---|---|
| Robustness (Ro) — scenario interval 0.06–0.81 (midpoint 0.44), Tier 3 MVT 0.40 indeterminate | |||
| Ro-4Poisoning Attack Resistance | 0.25w 0.25 | Ro-4 = 0.25 — basic validation exists through the platform's own build and deployment pipeline, but there is no adversarial screening of the runtime bundle, no signature or digest verification at promotion and no rejection of unsafe serialization, leaving the artifact channel poisonable with limited effort if write access is obtained. | Deployment artifacts staged in the tenant project include a pickle-serialized code.pkl alongside Dockerfile.zip and requirements.txt; the brief records that 'pickle-based serialization also raised a code-execution concern if the file could be manipulated'. The corresponding remediation is that 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' — controls not evidenced in the assessed configuration. Write access to that artifact was not demonstrated, so this is a latent ingestion path rather than an executed poisoning.source: brief |
| Fairness (Fa) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 3 MVT 0.45 indeterminate | |||
| Transparency (Tr) — scenario interval 0.17–0.72 (midpoint 0.45), Tier 3 MVT 0.45 indeterminate | |||
| Tr-3Audit Trail Completeness | 0.50w 0.25 | Tr-3 = 0.50 — the audit trail reconstructs common sessions at the API layer but has gaps for tool-mediated agent workflows: actor identity collapses to a shared managed identity, delegation lineage is absent, and the consumer/tenant/producer project boundary crossings cannot be tied back to a specific agent instance or authorizing user. | Two-sided. Cloud audit logging records the API calls the token made, which is what allowed the researchers' actions to be described concretely. What it cannot record is the agent dimension: AID-M-009.003 is rated Very High because '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'.source: brief |
| Tr-4Model Lineage Disclosure | 0.25w 0.20 | Tr-4 = 0.25 — limited lineage artifacts exist for the platform and base runtime, but material configuration lineage is incomplete: the effective permission set of the runtime identity, the tenant-project resource inventory and the producer-project dependencies were undocumented, which is precisely why the exposure was surprising to operators. | The brief's additional consideration asks 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' — i.e. the deployment's hidden service identities, non-editable OAuth scopes, tenant-project resources and producer-project dependencies were not disclosed to customers at the time. Google subsequently revised the documentation.source: brief |
| Privacy (Pr) — scenario interval 0.09–0.74 (midpoint 0.41), Tier 3 MVT 0.50 indeterminate | |||
| Pr-3Data Minimization Compliance | 0.25w 0.35 | Pr-3 = 0.25 — some minimization controls exist (project separation, IAM scoping as a mechanism) but secondary operational paths retain unnecessary data and expose it too widely: deployment artifacts persist in a staging location readable far beyond need, creating an unnecessary propagation path from build detail to any code running in the runtime. | The tenant project retained the deployment package — Dockerfile.zip, code.pkl and requirements.txt — readable by the runtime identity, and those files 'revealed internal paths and implementation details'. The runtime identity additionally held broad list and read access across storage that its workflow did not need, which the brief's remediation asks operators to strip: 'Remove broad list/read permissions that are not required, especially across tenant, build, staging, and production boundaries.'source: brief |
| Containment (Cn) — scenario interval 0.16–0.62 (midpoint 0.39), Tier 3 MVT 0.50 indeterminate | |||
| Cn-1Scope Enforcement | 0.25w 0.12 | Cn-1 = 0.25 — basic boundaries exist and blocked at least one high-impact action, but enforcement is inconsistent and far wider than the workload's job, so ordinary tool code exceeded intended scope across three project boundaries without manipulation of any control. | AID-I-002.001 is mapped because 'the metadata service, tenant project storage, customer buckets, and provider artifact registries should not all be reachable as one flat execution neighborhood' — in the assessed configuration they were. A single agent tool function reached the metadata service and, through the token, consumer-project storage and provider registries, without any escalation step. Against that, the boundary was not wholly absent: production image modification was blocked by separate controls.source: brief |
| Cn-2Escalation Prevention | 0.25w 0.16 | Cn-2 = 0.25 — basic role checks exist (IAM roles, OAuth scopes, and a provider-side block on production image modification) but they are vulnerable to delegated tool misuse: a tool can assume the runtime's full identity, and no just-in-time authorization or per-invocation binding stands between the tool and the credential. | The lowest-trust component in the deployment — an agent tool function — obtained the runtime's managed identity and then acted 'outside the normal agent flow', so whatever authorization the tool layer applied was bypassed rather than defeated. The brief states the point directly in AID-M-009.002: 'the extracted P4SA token bypassed the tool layer, so this envelope must be bound to the deployed identity and supplied to downstream authorization'.source: brief |
| Cn-5Agent Identity Integrity | 0.40w 0.14 | Between the Cn-5 0.25 and 0.50 anchors, scored 0.40. It exceeds 0.25 because this is a managed token-based identity with OAuth scoping, working authentication and provider-side revocation, not a shared secret; it falls short of 0.50 because that anchor requires token-based identity with genuinely scoped permissions, and the permission set here reached three project boundaries — and because there is no cryptographic binding to workload, session or tool invocation, so a stolen token is fully replayable. | The runtime authenticates as a broad Google-managed per-product service account whose bearer token is retrievable from the metadata service and replayable outside the agent flow. Authentication worked correctly — the token was valid and scoped in the IAM sense — but there is no binding to the agent instance, session or tool invocation, which is why AID-H-004.002 (dedicated service identity, short-lived audience-bound token, route binding, verifiable token provenance) and AID-M-009.003 (delegation lineage and authorization context) are both rated Very High. Effective permissions spanned consumer, tenant and producer projects.source: brief |
| Cn-6Action Reversibility Classification Rate | 0.25w 0.12 | Cn-6 = 0.25 — ad-hoc gating of selected high-impact actions with no formal reversibility taxonomy: a small number of provider-chosen operations are blocked outright, while the great majority of the action space executes with no pre-execution classification, so ARCR is well below 0.40 and no chain-composition rule exists. | AID-M-009.002 asks for 'a machine-checkable authority envelope for the Vertex AI agent across data classes, projects, registries, effect types, and mission scope' bound to the deployed identity — i.e. no such classification governed the runtime's actions. What did exist is an ad-hoc, provider-side gate on one selected high-impact effect: Google stated separate controls blocked production image modification. No classification applied to the actions the token actually took, because those actions bypassed the tool layer entirely.source: brief |
Unknown, not N/A: 15 applicable sub-metrics lack admissible public evidence. The lower, midpoint, and upper scenarios evaluate each at 0.00, 0.50, and 1.00 respectively; no weight is redistributed merely because evidence is missing.
Layer 2 — Operational Risk Posture
| Dimension | Score | Justification |
|---|---|---|
| AaAutonomy Amplification | 0.75w 0.20 | Scored exactly at the supervised-autonomy anchor and therefore not counted as elevated. The runtime executes tool-mediated workflows without per-action human approval and human oversight is asynchronous, which rules out the 0.50 anchor's escalation of high-value actions; it is held at 0.75 rather than 1.00 because the deployed agent's action authority in the assessed configuration is bounded by the customer's declared tool set, and every cross-boundary action the research demonstrated was a read rather than a transaction or state change. |
| AsAttack Surface Exposure | 0.80w 0.25 | Above the 0.75 anchor. The runtime is a hosted, network-reachable managed agent endpoint that ingests external task content and, critically, executes tool code supplied by the customer or third parties — the research premise is precisely an untrusted tool operating inside the trust boundary, which is worse than the 0.75 anchor's partially trusted external ingestion. It is held below 1.00 because the evidence establishes no external multi-agent or MCP communication surface for the assessed deployment. elevated |
| CpCascade Potential | 1.00w 0.30 | No System Dependency Graph is published for the deployment, so the worst-case default applies, and the 1.00 anchor is independently corroborated by the observed path. An ungated path runs from agent tool code (origin, operating at roughly write-internal privilege) to the metadata service and out with a credential-bearing identity — a P4 node, since the token is permission-carrying material — and then to customer-project storage and provider-side artifact registries, giving a privilege amplification depth of at least two and an ungated path reaching a P4 node. All four stack layers are implicated: model runtime, orchestration, tool layer, and downstream external systems in two other projects.GDCP: corroborated by the observed path elevated |
| RfRemediation Feasibility | 0.25w 0.25 | Customer-side remediation is deployment-infrastructure work measurable in days: migrate the agent to a dedicated BYOSA identity, grant only the buckets, endpoints, registries and APIs the workflow needs, block or tightly control metadata-service token access from tool code, segment the runtime's network path, and add detections for service-agent anomalies. No model change or retraining is involved. Scored at 0.25 rather than 0.00 to record that part of the exposure — the breadth of the platform's default managed identity — is a provider-side property the customer cannot patch, and Google's own response at the time was documentation and guidance rather than a permission change. |
Nelevated = 2 (dimensions strictly above 0.75) → CRM = 1.15.
Compound Risk Alert. Two or more dimensions are simultaneously elevated (spec 3.2.2); architectural decomposition is recommended before deployment.
Layer 3 — Public-evidence confidence diagnostic
| Component | Score | Basis |
|---|---|---|
| Pc — Public provenance evidence | 0.35 | Between the minimal and partial anchors. Above 0.25 because the platform, runtime class, managed-identity type and the deployment artifact inventory are all documented and were directly enumerable in the research (Dockerfile.zip, code.pkl, requirements.txt), which is more than a bare model-and-vendor record. Below 0.50 because the elements that matter most here were undisclosed at the time: the effective permission set of the managed identity, the non-editable OAuth scopes, the tenant-project resource inventory and the producer-project dependencies — the very transparency the brief has to ask providers for — and no identity policy or cryptographic provenance evidence was available to customers. |
| Ec — Public evaluation coverage | 0.35 | coverage 0.35 (8 of 23 applicable sub-metrics) × independence 1.00 × fidelity 1.00. No Full, Standard, or Lite pathway is claimed for a retrospective article. |
| Tf — Public-evidence freshness | 0.36 | Evidence dated 2026-03-31; age 135 days on the workpaper reference date. Components: T_containment 0.36 · T_calendar 0.60 · C_monitor 0.65 · C_event 0.65 · C_evidence 0.85. Binding term: T_containment. dt_days = 135, measured from the Unit 42 disclosure date 2026-03-31 to the assessment date 2026-08-13. agentic = true: an Agentic/MCP deployment whose permission boundary is mutable at runtime — service-account bindings, OAuth scopes and tool sets can all be reprovisioned — so the containment staleness floor applies, and it is the containment evidence (which identity the runtime holds and what it can reach) that this case is entirely about. baw = false: the evidence does not establish writable cross-session memory, runtime agent-to-agent messaging, self-modifying configuration or a closed feedback loop for the assessed deployment; a deployment using Agent Engine's session or memory features would meet the checklist and pull the behavioural floor in. C_monitor = 0.65 because the abuse would not have alerted: AID-D-011.004 states that 'authentication can succeed while the valid non-human identity is being abused', and the brief has to recommend adding detections for unusual bucket enumeration, restricted registry reads and metadata-token access, so those detections were absent. C_event = 0.65 rather than 0.35: the change event is a material guidance and documentation change (Google's BYOSA direction) affecting the assessed configuration's security assumptions, and there is no confirmed in-the-wild compromise — this was researcher-demonstrated — so the moderate-event cap is the honest one. C_evidence = 0.85 because the identity gaps remain open: the breadth of the default managed identity is a provider-side property and effective-permission transparency is still an outstanding ask. |
Public-evidence ACI = (Pc × Ec × Tf)1/3 = 0.35 — diagnostic status: Critical evidence limitation. It describes the evidence available to this case study, not the assurance of the underlying system, and is not inserted into the normalized-assurance scenario ERS.
Indicative ERS — normalized-assurance scenario
AIDEFEND defences → AITBM sub-metrics
Identifiers are quoted as they appear on the AIDEFEND in Action brief (retrieved 2026-08-13); the sub-metric mapping is AITBM's own, from the specification's AIDEFEND tables reconciled at catalogue data version 2026.08.05. AIDEFEND renumbers identifiers between releases, so the data version travels with every mapping and neither side's IDs should be cited without one. A mapping identifies a possible evidence route; a recommendation does not prove that the control was implemented or effective and receives no scoring credit by itself.
| Technique | Defence | Priority | Evidences |
|---|---|---|---|
| AID-M-005.002 | Policy-as-Code Configuration Baselines & Posture Release GatesParent AID-M-005 maps directly to Tr-3 in the reconciled AIDEFEND dataVersion 2026.08.05 crosswalk. This is the brief's primary control — approved service-account patterns, default-disabled broad storage and registry access, allowed OAuth scopes, metadata-service reachability and a BYOSA baseline — and it bears operationally on the Cn-1 and Cn-5 scores. | Very High | Tr-3 |
| AID-H-004.002 | Service & API AuthenticationParent AID-H-004 (Identity, Access & Trusted Communication for AI Systems). Both mapped legs are scored: a dedicated identity with a short-lived audience-bound token and verifiable provenance is the missing binding behind Cn-5 = 0.40, and token provenance is also what the audit trail could not record. | Very High | Cn-5 Tr-3 |
| AID-M-009.003 | Agent Identity, Delegation Lineage & Authorization ContextParent AID-M-009 (Agent Autonomy & Authority Governance). All three mapped sub-metrics are scored here; the technique's description — which agent instance acted, which user authorized it, which delegated scope it received — is also the direct evidence for the Tr-3 gap. | Very High | Cn-1 Cn-5 Cn-6 Cn-7 |
| AID-H-018.004 | Intent-Based Dynamic Capability ScopingParent AID-H-018 (Tool Authorization & Capability Scoping). Per-session capability envelopes are what would stop a narrow workflow agent inheriting broad project storage reads and registry discovery. | High | Cn-1 Cn-6 Cn-7 |
| AID-I-002.001 | Internal AI Network SegmentationParent AID-I-002 (Network Segmentation & Isolation for AI Systems) maps to Cn-4 in the catalogue; Cn-4 is not scored in this case because no timing, error, cache or telemetry side channel is evidenced. The technique's operational effect here is on the flat-reachability finding scored under Cn-1 — metadata service, tenant storage, customer buckets and provider registries in one neighbourhood — which is recorded rather than mapped. | High | Cn-4 |
| AID-H-003.002 | CI/CD Release Gating, Model Artifact Signing & Secure DistributionParent AID-H-003 (Secure ML Supply Chain Management). Both mapped legs are scored: artifact signing, immutable digests and rejection of unsafe serialization are the controls behind Ro-4 = 0.25, and the provenance record is part of the Tr-4 gap. | High | Ro-4 Tr-4 |
| AID-M-009.002 | Authority Envelope & Action Risk ClassificationDirect evidence for Cn-6 = 0.25: a machine-checkable authority envelope across data classes, projects, registries and effect types did not exist, and the brief notes the extracted token bypassed the tool layer where any such envelope would have been applied. | Medium | Cn-1 Cn-5 Cn-6 Cn-7 |
| AID-D-011.004 | Non-Human Identity & Delegated Token Abuse DetectionParent AID-D-011 (Registered Agent Behavior, Interaction & Identity-Abuse Detection). Its absence is the basis for C_monitor = 0.65: authentication succeeds while a valid non-human identity is abused, and no correlation existed between token issuance, agent request, downstream resource and project boundary. | Medium | Cn-5 Cn-6 |
| AID-D-011.001 | Agent Behavioral Analytics & Anomaly DetectionSame parent. Baselining expected tool calls, storage access, network destinations and credential use per agent class is what would flag an agent that starts harvesting tokens; note that this is a detection control scored point-in-time in the IVP, distinct from the behavioural freshness floor, which does not apply here because the BAW checklist is not met. | Medium | Cn-5 Cn-6 |
WHAT THIS CASE TEACHES
Authentication succeeded and the provider's write boundary held, so the failure has to be located precisely rather than described as 'broken identity': AITBM puts it in Cn-5 = 0.40 (a valid managed token with no binding to agent instance, session or invocation) and Cn-1 = 0.25 (flat reachability across three project boundaries), while Tr-3 stays at 0.50 because cloud audit logging did record the calls it could not attribute.
Sources: AIDEFEND in Action brief: Vertex AI Double Agents: When Service-Agent Defaults Become an Agentic Cloud Boundary (2026-04-25) · Unit 42, Palo Alto Networks (Ofir Shaty), Double Agents: Exposing Security Blind Spots in GCP Vertex AI (2026-03-31)