Google Vertex AI and WorkOS split the agent identity stack

At a glance

What this is: This is an analysis of how Google Vertex AI and WorkOS operate at different layers of the AI stack, with the key finding that agent runtime security and enterprise authentication are separate problems.

Why it matters: IAM teams need to separate in-cloud workload controls from customer identity, lifecycle, and MCP authorization if they want AI systems to be governable across NHI, autonomous, and human identity programmes.

By the numbers:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years.

👉 Read WorkOS's analysis of Google Vertex AI vs enterprise authentication

Context

Agent identity is not the same thing as enterprise authentication. Vertex AI manages agents and models inside Google Cloud, but the article makes clear that customer SSO, SCIM lifecycle, and app-level authorization remain separate governance problems. For IAM teams, the key question is which layer owns the decision, the runtime perimeter, or the business application.

MCP changes that boundary because tool access now needs OAuth 2.1, token validation, and scope control that work outside a single cloud perimeter. That makes the topic relevant to NHI governance, autonomous systems access, and human identity programmes at the same time, because the same agent may touch infrastructure, data, and user-facing business systems.

Key questions

Q: How should security teams govern AI agents that run in one cloud but access customer systems elsewhere?

A: Security teams should split governance between runtime controls and enterprise authorization. Cloud IAM can govern what the agent can do inside the hosting environment, but customer SSO, SCIM, tenant permissions, and audit trails must still be enforced at the application boundary. The key is to treat hosting and trust as separate control planes.

Q: Why do AI agents complicate existing IAM and NHI governance models?

A: AI agents complicate governance because access is no longer confined to a single environment or a single identity type. An agent may need cloud runtime permissions, customer data access, and tool-level OAuth tokens at the same time, which means standing privilege and lifecycle assumptions break down fast. That is why one control model rarely covers the full path.

Q: What breaks when MCP tool access is not explicitly authorized?

A: When MCP tool access is not explicitly authorized, the agent can inherit trust from the hosting platform without proving it should reach the target system. That creates hidden privilege expansion, weak revocation, and poor auditability. Teams need per-tool scopes, client registration, and token validation to keep the access boundary visible.

Q: How do IAM teams decide whether to use cloud-native identity or an external auth layer?

A: Use cloud-native identity for the workload running inside the cloud, and use an external auth layer when the system must integrate with customer IdPs, tenant lifecycle workflows, or cross-cloud MCP access. The deciding factor is not where the code runs, but where the trust decision must be enforced.

Technical breakdown

Vertex AI agent runtime and Google Cloud IAM

Vertex AI Agent Builder combines an agent development kit, managed runtime, observability, and memory services with Google Cloud primitives such as IAM roles, service accounts, VPC Service Controls, Private Service Connect, and CMEK. That means the platform can govern where agents run and what GCP resources they may touch, but only inside the boundaries of the cloud project and the controls already present in that environment. The article also notes emerging agent identity features, which make agent access more visible inside Google Cloud but do not replace enterprise identity governance.

Practical implication: map agent runtime permissions separately from business application access and do not treat cloud IAM as a full enterprise auth model.

MCP authorization for tools and external services

MCP introduces a tool and data access layer that sits between an agent and the systems it calls. OAuth 2.1, PKCE, metadata discovery, dynamic client registration, and JWT validation are the control points that decide whether an MCP client can obtain and use access tokens safely. The real issue is that tool access can exist outside the cloud where the agent runs, so authentication must be portable and scope-bound rather than assumed from the host environment. This is why MCP governance belongs in the identity layer, not just the platform layer.

Practical implication: treat every MCP connection as an authorization surface with explicit scopes, token checks, and client registration rules.

Enterprise SSO, SCIM, and fine-grained authorization for B2B SaaS

WorkOS is positioned in the identity plane that many AI platforms do not cover: enterprise SSO, directory sync, fine-grained authorization, and audit logs for customer-facing applications. The article shows why this matters for B2B SaaS using agents, because business customers expect their own IdP, their own lifecycle workflows, and permissions that are independent of the cloud where the agent executes. In practice, the agent can be hosted anywhere, but the user, tenant, and resource authorization model still has to be enforced at the application boundary.

Practical implication: separate customer identity integration from agent hosting so provisioning, deprovisioning, and access policy remain controllable.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.

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 Cloud IAM and enterprise authentication solve different identity problems. The article is clear that Vertex AI controls agents inside Google Cloud, while enterprise SSO, SCIM, and app-level authorization live elsewhere. That separation matters because many teams still assume cloud-native IAM can stand in for customer identity governance. It cannot, and the implication is that agent programmes need two control planes, not one.

MCP makes tool access an identity problem, not just an integration problem. OAuth 2.1, dynamic client registration, PKCE, and JWT validation are now part of how agents and tools negotiate trust. That means the access decision is no longer hidden inside the application stack, and the practitioner question becomes who owns token scope, client identity, and revocation across systems.

Runtime perimeter controls do not eliminate identity blast radius. VPC Service Controls, CMEK, and observability can constrain where data moves, but they do not answer who may act on behalf of a tenant, a user, or an agent. When agents can call connectors, APIs, and MCP tools, the blast radius is defined by authorization scope, not by deployment location alone. Practitioners should treat scope design as a first-class governance control.

Identity lifecycle for AI agents must be governed as rigorously as human lifecycle. The article’s SCIM and directory sync framing shows that provisioning and deprovisioning remain central, even when the actor is an agent rather than a user. That is a NHI governance pattern with human-IAM parallels: access that is not retired with the business relationship becomes residual trust. The practical conclusion is that lifecycle controls must follow the actor, not the platform.

Tool-scoped access creates a new named concept: identity boundary split. This is the point where cloud runtime identity and enterprise authorization diverge, and neither layer alone is sufficient. The split is especially visible in B2B SaaS with AI features, where a model may run in one cloud but must still honour customer IdPs, tenant permissions, and MCP scopes. Practitioners need to design for the split explicitly instead of assuming a single platform can own it all.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• That same survey found that only 44% of organisations have implemented any policies to manage their AI agents, even though 92% say governance is critical.
• For a deeper operating model, see OWASP Agentic Applications Top 10 for the control failures that appear when tool use and identity drift converge.

What this signals

Identity boundary split: the practical programme risk is assuming one control layer can govern both cloud-hosted agents and customer-facing authorisation. IAM leads should expect more work to move into application-boundary controls, because the cloud perimeter does not resolve tenant trust or tool-scoped access by itself.

With 53% of security leaders expecting AI to run major portions of infrastructure autonomously within three years, per the 2026 Infrastructure Identity Survey, teams need to plan for more than pilots. The operating model has to cover provisioning, revocation, auditability, and policy ownership across cloud and SaaS layers.

The most immediate preparation is not a new platform purchase but a governance map that shows where agent identity ends and enterprise authorization begins. That map should include SSO, SCIM, MCP scopes, and the external IdPs that actually control business access.

For practitioners

• Separate runtime identity from customer identity Document which controls belong to Google Cloud runtime administration and which belong to enterprise application access. Use that split to assign ownership for SSO, SCIM, tenant permissions, and agent runtime policy.
• Scope MCP access at the tool boundary Require OAuth 2.1, PKCE, and explicit tool scopes for every MCP server and client connection. Validate token audience, registration status, and revocation paths before any tool call is allowed.
• Review agent access as a lifecycle control Tie provisioning and deprovisioning of agent identities to the same governance process used for customer access and workload credentials. Remove stale agent grants when tenants, vendors, or environments change.
• Measure authorization outside the cloud perimeter Test whether an agent can still reach enterprise data or tools after its host project is locked down. If the answer is yes, the remaining control gap is in application authorization, not infrastructure policy.

Key takeaways

• Vertex AI and WorkOS solve different identity problems, so treating them as substitutes creates governance blind spots.
• MCP turns tool access into a first-class authorization surface, which makes token scope and client identity central controls.
• AI agent programmes need separate ownership for runtime access, customer identity, and lifecycle management if they are to stay governable.

Key terms

• Identity boundary split: The point where cloud runtime identity and enterprise application authorization diverge. One layer governs where an agent runs, while the other governs who or what may act on a tenant, resource, or tool. In AI systems, treating those as the same boundary leaves access scope and accountability unclear.
• MCP authorization: The identity and access controls that sit in front of Model Context Protocol tools and data sources. It usually includes OAuth 2.1, client registration, token validation, and scoped permissions. For agents, this is the control plane that decides whether a tool call is legitimate before execution starts.
• Agent lifecycle governance: The governance process that provisions, reviews, and retires access for AI agents and other non-human identities. It applies the same lifecycle discipline used for human users, but it must account for machine speed, dynamic tool use, and the fact that agent access often spans more than one platform.

Deepen your knowledge

AI agent identity boundaries, MCP access, and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a control model for agents that cross cloud and application boundaries, it is worth exploring.

This post draws on content published by WorkOS: Google Vertex AI vs. WorkOS: ML Platform Meets Enterprise Authentication. Read the original.