Vertex AI misconfigurations expose privilege escalation in cloud AI

At a glance

What this is: This is an analysis of how Vertex AI service-agent misconfigurations can turn cloud AI workflows into privilege-escalation paths and data-exposure risks.

Why it matters: It matters because IAM teams now have to govern platform-managed identities and custom job permissions as part of the same access-control model, not as separate cloud operations tasks.

👉 Read Unosecur's analysis of Vertex AI misconfigurations and cloud privilege escalation

Context

Vertex AI service agents are cloud-managed identities that let the platform act on a customer’s behalf. When those identities receive broader permissions than the workload needs, the result is not just configuration drift but a privilege pathway that can be abused from inside AI operations.

Unosecur’s article argues that the governance failure sits in identity design, not in AI branding. The relevant question for IAM and cloud security teams is whether service agents, custom jobs, and container execution are bounded by least privilege and monitored as identity events, not just as workload events.

Key questions

Q: What breaks when Vertex AI service agents are over-permissioned?

A: The service agent stops being a narrow workload identity and becomes a privileged cloud access path. That can let an attacker pivot from a single custom job into metadata access, credential exposure, and broader resource compromise. The failure is excessive trust in the platform account, not the AI workload itself.

Q: Why do AI workloads increase the risk from existing cloud misconfigurations?

A: AI speeds up discovery, exploitation and follow-on action, so a weak control that once stayed latent can be abused much faster. Misconfigured storage, exposed services and stale credentials remain the same weaknesses, but the time between exposure and impact shrinks sharply when automation is present.

Q: What are the signs that Vertex AI permissions are too broad?

A: Look for service agents with project-wide roles, custom jobs that can be created by too many users, and AI environments that can access metadata or sensitive storage without a clear business need. Those are practical indicators that workload identity scope is larger than the task boundary.

Q: How should teams govern AI agent identity across cloud platforms and production systems?

A: They should treat each agent as a governed identity with explicit access boundaries, session rules, and revocation points. The control objective is to keep production reach aligned to task scope across cloud platforms, because delegated agent access becomes dangerous when it is durable and diffuse.

Technical breakdown

Why Vertex AI service agents become an access-control problem

Vertex AI uses service agents to run platform functions on behalf of customers, which means these identities sit between orchestration and cloud resources. If the service agent is given broad project-wide rights, an attacker who can influence a job or container can inherit more capability than the workload should have had. The issue is not that AI workloads are special, but that the identity binding between platform action and cloud permission is often too coarse. In practice, the service agent becomes a privileged control plane identity rather than a narrowly scoped workload identity.

Practical implication: inventory Vertex AI service agents as privileged identities and review their role scope against the exact jobs they support.

How misconfigured custom jobs enable privilege escalation

Custom training jobs are meant to provide flexibility, but they also create an execution surface where attacker-controlled code can run if permissions are weak. Unosecur points to misused permissions such as aiplatform.customJobs.create as a way to launch unauthorized jobs inside training environments. Once code executes there, attackers can move from workload abuse to cloud privilege escalation by abusing the surrounding trust context, including metadata access and credential exposure. This is a classic identity-to-execution path: the job is the foothold, the over-permissioned service identity is the enabler.

Practical implication: treat custom job creation as a privileged action and restrict who can create or modify training jobs in production projects.

Why metadata and credential exposure turn an AI misconfiguration into a breach

When a workload can reach metadata services or overbroad secrets, the attack stops being about an AI platform setting and becomes a cloud compromise pattern. Vertex AI environments that inherit excessive access can expose credentials, keys, or other sensitive cloud resources after privilege escalation. That matters because the blast radius extends beyond the model lifecycle into adjacent storage, IAM, and project resources. The technical failure is that the workload’s effective authority exceeds its intended task boundary, so a single misconfigured path can cascade across the cloud estate.

Practical implication: isolate Vertex AI workloads from sensitive credential paths and verify that metadata and secret access are explicitly denied where unnecessary.

Threat narrative

Attacker objective: The attacker aims to turn a misconfigured AI workload into broader cloud access and extract sensitive data or credentials.

1. Entry begins when an attacker abuses over-permissioned Vertex AI service-agent access or a misconfigured custom job creation path.
2. Credential access follows when the compromised workload can reach metadata or other cloud-authenticated resources.
3. Privilege escalation occurs as the attacker pivots from the training environment into broader project-level permissions and adjacent cloud services.
4. Impact is achieved when sensitive data, credentials, or model-adjacent assets are exposed or exfiltrated.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Vertex AI misconfiguration is an identity problem before it is an AI problem. The article describes service agents that carry more authority than their tasks require, which is a cloud IAM failure disguised as platform convenience. Once the platform identity is over-scoped, every downstream AI action inherits that excess access. Practitioners should treat AI service agents as governed identities, not background infrastructure.

Over-permissioned service agents create identity blast radius in cloud AI. The central risk is not the model itself but the way platform-managed accounts inherit project-wide access and can reach secrets, metadata, and adjacent services. That expands the blast radius far beyond the training job boundary. IAM teams should read this as a reminder that workload identity scope now determines AI security scope.

Vertex AI misconfigurations sharpen the case for least privilege at the workload layer. A custom job should only see the resources required to execute that job, and no more. When the identity granted to the platform can create jobs, read metadata, and touch sensitive storage, the control boundary has already failed. The practitioner takeaway is to govern AI workloads with the same precision used for privileged cloud services.

Cloud AI governance needs a named concept: identity blast radius. In this pattern, a single over-permissioned platform account amplifies one configuration mistake into multi-resource exposure. That is why AI security teams cannot separate workload configuration from identity governance. The implication is to measure AI risk by the reach of the service identity, not by the novelty of the AI platform itself.

From our research library:

• 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
• Read next: Privileged Access Management Guide

What this signals

Identity blast radius: AI platform misconfigurations are most dangerous when the service identity can reach resources well beyond the job’s intended scope. That means cloud AI governance has to start with role design, not after-the-fact detection.

Teams that run Vertex AI should expect IAM review to move closer to deployment time. A custom job, a service agent, and a storage path are now one governance problem, because a weakness in any one of them can expose the others.

For practitioners

• Audit Vertex AI service-agent scope Review every Vertex AI service agent and compare its roles to the exact jobs, data stores, and APIs it needs. Remove project-wide permissions that are not strictly required for the workload.
• Restrict custom job creation Limit who can create or modify custom training jobs, especially in production projects. Treat job creation as a privileged action because it can become an execution entry point.
• Separate AI workloads from sensitive cloud resources Block unnecessary metadata, secret, and storage access from AI execution environments. Use dedicated identities and isolated resource paths so a compromised job cannot pivot broadly.
• Monitor unauthorized job activity Alert on unusual job creation, container changes, and service-agent role expansion. Tie those events to identity threat detection so privilege abuse is visible before data moves.
• Use least-privilege role design for AI platforms Replace broad default bindings with narrowly defined custom roles for Vertex AI service agents and related automation accounts. Re-certify those bindings when workloads or project boundaries change.

Key takeaways

• Vertex AI misconfiguration is fundamentally a workload identity issue, because the platform account can inherit more access than the AI job genuinely needs.
• The article shows how that overreach can open a path from custom job execution to credential exposure and broader cloud privilege escalation.
• Least privilege, tighter job creation rights, and identity-aware monitoring are the controls that most directly reduce the attack surface.

Key terms

• Service Agent: A service agent is a platform-managed non-human identity that performs actions on behalf of a cloud service. In AI platforms, it often bridges orchestration and resource access, so its permissions determine how far a compromised job can move across the environment.
• Privilege Escalation: An attack technique where a compromised identity, often an NHI with initially limited permissions, exploits vulnerabilities or misconfigurations to gain elevated access rights, typically leading to broader compromise.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• Examples of Vertex AI permissions that commonly create excess access in cloud projects
• The article’s walkthrough of how misconfigured service agents can be abused during custom job execution
• Specific examples of where metadata access and storage exposure can expand the blast radius
• The vendor’s recommended controls for tightening identity scope in AI workflows

👉 The full Unosecur blog expands on service-agent risk, custom job abuse, and mitigation steps for AI workloads.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.