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

Why This Matters for Security Teams

Over-privileged Vertex AI identities are not just an IAM hygiene issue. They create a governance gap where model deployment, tuning, data access, and tool invocation can all be combined into a single blast radius if ownership is unclear. NHI Management Group’s Ultimate Guide to NHIs shows that 97% of NHIs carry excessive privileges, which is a strong signal that overreach is usually systemic, not accidental. For AI platforms, that matters because the identity is often tied to automation, not a person sitting behind a console. Security teams commonly focus on who executed the action, but accountability starts earlier, with who approved the entitlement, who owns the workload lifecycle, and who is responsible for revocation when the use case changes. The practical control question is not only “who did it?” but “who allowed an identity to retain standing access it did not need?” That is why the OWASP Non-Human Identity Top 10 is useful here: it frames privilege, lifecycle, and secret exposure as NHI problems, not just cloud admin mistakes. In practice, many security teams discover this only after a model or service account has already been used to reach data it should never have touched.

How It Works in Practice

Accountability for an over-privileged Vertex AI identity usually needs to be assigned across three layers: the programme owner who requested access, the platform team that provisioned it, and the cloud or IAM team that permitted broad entitlements without lifecycle controls. The important part is that these are distinct responsibilities. One team should own business justification, another should own technical enforcement, and a third should own periodic review and offboarding. A workable operating model usually includes:

• Identity ownership recorded at the workload or project level, not buried in a generic cloud admin group.
• Separate approval paths for model invocation, tuning, deployment, dataset access, and secret sharing.
• Short-lived credentials and just-in-time provisioning rather than long-lived standing access.
• Policy evaluation at request time, using context such as project, environment, data sensitivity, and intended action.
• Regular entitlement reviews that verify the identity still needs access to the exact resources it can reach.

For AI-specific risk, current guidance suggests pairing IAM with runtime governance, because a model or agent can chain actions in ways that are not obvious at provisioning time. That is why NIST Cyber AI Profile (IR 8596) is relevant: it reinforces the need for governance, monitoring, and controlled use of AI systems rather than assuming static entitlements are enough. NHI Management Group’s Top 10 NHI Issues is also directly relevant because excessive privileges and weak lifecycle management repeatedly show up as root causes. These controls tend to break down when multiple teams share responsibility for the same Vertex AI project because no single owner feels accountable for revocation after deployment changes.

Common Variations and Edge Cases

Tighter entitlement control often increases operational overhead, requiring organisations to balance rapid AI delivery against governance and auditability. That tradeoff is especially visible when data science, platform engineering, and security all need different levels of access to the same Vertex AI environment. Best practice is evolving, but there is no universal standard for whether the model owner, platform owner, or application owner should be the primary approver in every case. The safest pattern is to assign primary accountability to the business or programme owner, with the platform team accountable for technical enforcement and security accountable for independent review. Edge cases matter. In shared test environments, broad access may be tolerated temporarily, but it should still be time-bound and traceable. In multi-tenant projects, a single over-privileged service account can expose multiple datasets or models, so the accountability model has to extend beyond one workload. In managed agentic workflows, the risk is higher because autonomous actions can expand privileges indirectly through chained tools or delegated tokens. Where identities are shared across pipelines, current guidance suggests treating them as high-risk NHIs and requiring explicit owners, not inherited access. This aligns with the operational lessons in the 52 NHI Breaches Analysis: weak ownership and excessive privilege usually turn into incident response problems long before they become policy exceptions.

Related resources from NHI Mgmt Group

• Who is accountable when an AI agent or workflow executes privileged actions under a forged identity?
• Who is accountable when a non-human identity is over-privileged?
• Who is accountable when a workload identity is over-privileged?
• Who is accountable when a non-human identity is over-privileged or left active after offboarding?