Google Vertex AI exposes a new identity governance surface

At a glance

What this is: This analysis argues that Google Vertex AI creates a distinct identity governance surface where model access, tuning, and sharing behave like privileged access.

Why it matters: It matters because IAM, IGA, PAM, and workload identity teams must govern AI model access as a security boundary, not just a cloud service permission set.

👉 Read P0 Security's analysis of identity governance risks in Google Vertex AI

Context

Google Vertex AI makes model invocation, fine-tuning, and deployment part of the identity problem, because those actions can expose data, change model behaviour, and propagate access across projects. In practice, the question is not whether AI is useful, but whether enterprise governance can keep pace with the way model privileges are assigned and reused.

In multi-team GCP environments, a shared model platform can become a shared trust boundary unless permissions, provenance, and auditability are tightly controlled. That creates overlap between NHI governance, workload identity, and human access oversight, especially when service accounts and federated identities are reused across development and production.

Key questions

Q: How should security teams govern Google Vertex AI access in production environments?

A: Treat Vertex AI permissions as privileged access, not ordinary application access. Split model invocation, training, deployment, and sharing into separate roles, require short-lived credentials where possible, and tie each action back to an authoritative identity source. That gives IAM, IGA, and PAM teams a practical way to reduce blast radius across AI workloads.

Q: Why do AI model platforms like Vertex AI complicate least-privilege design?

A: Because a single identity can often invoke models, create pipelines, and move content across projects or regions. That combines data exposure, model integrity, and propagation risk in one access path. Least privilege therefore has to reflect purpose and lifecycle stage, not just the narrowness of a role name.

Q: What breaks when service accounts are reused across Vertex AI projects?

A: Reuse breaks attribution, separation of duties, and project-level containment. A shared identity can make it impossible to tell which team invoked a model, which environment changed it, or whether a sandbox access path reached production. That turns audit logs into activity records without reliable accountability.

Q: Who is accountable when a Vertex AI identity is over-privileged?

A: Accountability sits with the programme owners who assigned broad access without lifecycle controls, not just with the person or workload that used it. IAM, cloud security, and platform teams need clear ownership for who can invoke, tune, deploy, and share models, because each of those actions carries separate risk.

Technical breakdown

Vertex AI permissions turn model use into privileged access

Vertex AI actions such as prediction, explanation, training pipeline creation, and model upload are ordinary cloud permissions on the surface, but they carry privileged consequences. Invocation rights can expose sensitive prompts or trigger unmonitored usage, while model registration and pipeline permissions can alter the behaviour of shared models. In a mature identity programme, these are not generic application entitlements. They are high-risk privileges tied to data exposure, model integrity, and cost control. The practical issue is that broad default roles can quietly collapse the separation between experimentation and production access.

Practical implication: Treat Vertex invocation and model lifecycle permissions as privileged access and scope them by job, project, and business purpose.

Cross-project access creates a shared identity boundary

Vertex is tightly coupled to Google Cloud Resource Manager, which means a model or endpoint can be consumed across projects if governance is loose. That is useful for scale, but it also creates propagation paths for access that bypass the intent of project isolation. If a sandbox project can call a production model, the platform has effectively crossed from local workflow control into enterprise boundary management. Cross-region invocation adds a second layer of policy risk when data residency requirements differ. Identity governance must therefore follow the model, not just the project.

Practical implication: Apply project hierarchy, region restrictions, and trusted-project allow lists before cross-team model sharing becomes uncontrolled.

Auditability depends on stable identity provenance

Cloud audit logs only help if requests can be mapped back to a durable human or workload identity. In Vertex environments, that becomes difficult when service accounts are long-lived, API keys are shared, or workload identity federation is inconsistently configured. The result is a log trail that records activity but not accountable origin. For security and compliance teams, that is a governance failure, not a logging issue. If an inference request cannot be tied to the authoritative identity source, investigation, access review, and accountability all lose precision.

Practical implication: Normalise federated identities and require each model action to resolve back to one authoritative identity record.

Threat narrative

Attacker objective: The objective is to use legitimate Vertex AI access to expose data, alter model behaviour, and extend control across projects while remaining difficult to attribute.

1. Entry occurs when a broad Vertex AI role, shared service account, or federated workload identity can reach production endpoints or model lifecycle APIs.
2. Escalation follows when the same identity can invoke models, create training pipelines, or register new versions across projects and regions without tight contextual limits.
3. Impact is the exposure of sensitive inputs, unvetted training content, governance bypass, and an audit trail that cannot reliably attribute model actions to a single accountable identity.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Google Vertex AI has turned model access into a privileged identity problem. The permission to invoke, tune, or register models is not a routine cloud entitlement because it can expose sensitive inputs and alter shared model behaviour. That shifts Vertex governance from platform administration into access governance, where least privilege and separation of duties have to operate across the full model lifecycle. Practitioners should treat model invocation as a privileged action, not a convenience feature.

Cross-project model sharing creates a shared trust boundary, not an isolated sandbox. When Vertex permissions flow across projects, regions, and reused service accounts, the platform stops behaving like a bounded development tool and starts behaving like an enterprise access fabric. That is why project hierarchy alone does not solve the problem. The implication is that identity governance must follow the model path, not the resource owner.

Identity provenance becomes the deciding control in Vertex environments. Audit logs are only useful when every model action can be resolved back to a stable, authoritative identity. Long-lived service accounts, shared API keys, and inconsistent federation mappings were designed for access continuity, not for accountable AI operations. The implication is that programme owners need to rethink how accountability is established for machine-driven model activity.

Least privilege for AI workloads must include lifecycle boundaries, not just role scope. A role that looks narrow at assignment time can still become overpowered if it is reused across training, deployment, and inference. That is the identity governance gap Vertex exposes: access definitions often assume the same identity will keep the same purpose across the full model lifecycle. Practitioners should build controls around purpose, context, and lifecycle stage, not static entitlement lists.

Identity blast radius is the right concept for Vertex governance. A compromised or over-privileged identity in Vertex can affect data exposure, model integrity, auditability, and cross-project propagation at the same time. That combination makes blast radius more useful than point-in-time access review as the governing idea. The implication is that identity teams should measure how far a single Vertex permission can travel before it reaches production impact.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to the same report.
• For a deeper model of workload identity control, compare that with Guide to SPIFFE and SPIRE, which shows how workload identity is meant to be attested and constrained.

What this signals

Identity governance for AI platforms will increasingly be judged by provenance, not just permissioning. As organisations push more workloads into model platforms, the question shifts from who can click deploy to whether every model action can be traced back to a stable, authoritative identity record. That makes identity provenance a programme-level requirement rather than an audit-afterthought.

Vertex-style platforms expose a governance gap between role assignment and operational reality. Security teams that still rely on broad, durable access are going to see more drift between intended use and actual model activity. The practical signal is that JIT access, separation of duties, and project boundary enforcement need to be measured as one control chain, not as isolated hygiene tasks.

AI agents already behaving beyond scope is a warning for adjacent model ecosystems. With 80% of organisations seeing agent actions beyond intended scope in our research, the same pattern of overreach will pressure adjacent identity controls around model invocation, shared service accounts, and cross-project access. Teams should expect policy exceptions to surface first in AI platforms, then propagate into broader IAM programmes.

For practitioners

• Classify Vertex permissions as privileged access Review aiplatform permissions the same way you review other high-risk entitlements. Separate model invocation, training, upload, and sharing into distinct approval paths so broad roles do not collapse governance into one control bucket.
• Enforce separation of duties across the model lifecycle Keep model builders, model approvers, and production consumers on different identities and different role sets. That reduces the chance that one account can both change a model and run it in production.
• Normalise workload identity provenance Map Cloud Run, GKE, and CI/CD identities back to the authoritative enterprise IdP and avoid shared service accounts where possible. This makes inference requests and pipeline actions attributable during audit or incident review.
• Constrain cross-project and cross-region use Use organisational policies, approved project boundaries, and region restrictions to stop a sandbox model from becoming callable in production or a regulated region from being bypassed.
• Apply just-in-time access for model operations Replace standing access with short-lived credentials that expire after the specific model task is complete. That limits the exposure window for compromised credentials and reduces dormant privilege.

Key takeaways

• Vertex AI turns model invocation, tuning, and sharing into privileged identity actions that deserve the same control discipline as other high-risk access.
• Cross-project reuse, shared service accounts, and weak provenance can silently defeat separation of duties and make audit logs hard to trust.
• Practitioners should constrain model access with least privilege, JIT credentials, and identity provenance controls before AI platforms become the easiest way to bypass governance.

Key terms

• Vertex AI identity surface: The set of permissions, credentials, and trust relationships that govern who or what can invoke, tune, deploy, or share models in Vertex AI. It extends beyond cloud administration because model actions can expose data, change behaviour, and move across projects or regions.
• Identity provenance: The ability to trace each AI-related action back to a verified human or workload identity in the authoritative directory or federation source. In AI platforms, provenance is what makes audit evidence usable, because activity without accountable origin is hard to investigate or certify.
• Cross-project trust boundary: A control boundary that exists when a model, endpoint, or service account can operate across multiple projects. It matters because a misstep in one project can propagate into another, so governance must be set at the boundary where access can travel, not just where it starts.
• Identity blast radius: The extent of impact a single identity can cause if it is compromised, over-privileged, or misused. In AI environments, blast radius includes data exposure, model tampering, cost escalation, and audit failure, which makes scope control more important than static role assignment.

What's in the full article

P0 Security's full analysis covers the operational detail this post intentionally leaves for the source:

• Permission-by-permission breakdown of Vertex AI actions such as invocation, training, model upload, and endpoint explanation.
• The specific GCP role patterns and privilege combinations that create overexposure in production AI environments.
• Practical governance steps for cross-project model sharing, regional restrictions, and workload identity federation.
• The author’s full examples of how audit logs, service accounts, and CI/CD identities interact in Vertex deployments.

👉 The full P0 Security post covers Vertex AI permission risks, cross-project propagation, and auditability gaps.

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.