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

Why This Matters for Security Teams

When service accounts are reused across Vertex AI projects, the failure is not just technical convenience. It removes the identity boundary that lets teams answer basic questions about who invoked what, from where, and under which controls. That matters because AI workloads are increasingly operational, not experimental, and shared identities undermine both least privilege and incident response. NIST’s Cybersecurity Framework 2.0 still expects clear accountability and controlled access, but reused accounts blur both.

This problem also shows up in NHI governance because the account is no longer just a login. It becomes the machine identity behind model calls, dataset access, deployment changes, and downstream tool use. Once that identity is shared, project-level blast radius expands and audit trails lose their forensic value. NHIMG’s 52 NHI Breaches Analysis shows how identity misuse and weak separation consistently turn routine access into a security failure. In practice, many security teams encounter attribution gaps only after a cross-project incident has already made the audit log ambiguous.

How It Works in Practice

Vertex AI projects work best when the service account attached to a workload is scoped to one project, one environment, and one operational purpose. Reuse across projects collapses those distinctions. A model test in a sandbox, a prompt pipeline in staging, and a production endpoint update can all appear to come from the same principal, which makes it impossible to distinguish legitimate automation from unauthorized reuse.

The safer pattern is to treat each project as a separate trust boundary and issue distinct non-human identities for each workload. That supports separation of duties, clearer logging, and cleaner revocation. Current guidance suggests combining project-scoped service accounts with short-lived credentials, conditional access, and policy enforcement at request time rather than relying on static role grants. The NIST identity model and the NIST CSF 2.0 both reinforce that identity should be tied to accountability and risk management, not convenience.

• Use one service account per Vertex AI project, not one shared across environments.
• Grant only the permissions required for that project’s model, data, and deployment path.
• Separate training, evaluation, and production identities so logs preserve operational context.
• Rotate or revoke credentials independently when a project is retired or compromised.
• Bind access decisions to workload context, such as project, pipeline, and environment tags.

NHIMG’s Ultimate Guide to NHIs is useful here because it frames service accounts as machine identities that must be governed as first-class security objects, not shared admin conveniences. These controls tend to break down when platform teams centralise identities for speed because every project then inherits the same trust assumptions.

Common Variations and Edge Cases

Tighter service account isolation often increases operational overhead, requiring organisations to balance deployment speed against traceability and blast-radius reduction. That tradeoff becomes visible in multi-team Vertex AI environments where shared CI/CD pipelines, reusable notebooks, or central platform projects encourage identity reuse.

There is no universal standard for how much reuse is acceptable, but current guidance suggests that any shared identity should be exceptional, documented, and time-bound. If a platform team insists on a common account, it needs compensating controls such as stronger logging, explicit approval workflows, and environment-specific policy gates. Even then, the shared identity still weakens attribution. The risk is higher when sandbox and production projects can reach the same datasets, because a single compromised credential can cross boundaries without a clear owner to investigate.

NHIMG’s DeepSeek breach illustrates how quickly exposed credentials and weak containment can expand impact across sensitive systems. For teams operating at scale, the right question is not whether one service account is easier to manage, but whether the organisation can still prove who did what after an event. That answer is often no when service accounts are reused across projects.

Related resources from NHI Mgmt Group

• What breaks when signing keys are reused across projects?
• What breaks when service accounts are reused across pipeline environments?
• What breaks when prompt injection meets shared service accounts?
• What problem does ownership attribution solve for service accounts and API keys?