TL;DR: Google Vertex AI covers agent runtime, model hosting, observability, and in-cloud IAM inside Google Cloud, while WorkOS handles enterprise SSO, SCIM, fine-grained authorization, and OAuth 2.1 for MCP across any cloud, according to WorkOS. The identity problem is no longer just where agents run, but where customer trust, lifecycle, and tool access are enforced.
NHIMG editorial — based on content published by WorkOS: Google Vertex AI vs. WorkOS: ML Platform Meets Enterprise Authentication
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.
Questions worth separating out
A: Security teams should split governance between runtime controls and enterprise authorization.
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.
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.
Practitioner guidance
- Separate runtime identity from customer identity Document which controls belong to Google Cloud runtime administration and which belong to enterprise application access.
- Scope MCP access at the tool boundary Require OAuth 2.1, PKCE, and explicit tool scopes for every MCP server and client connection.
- 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.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- The specific Vertex AI capabilities in Agent Builder, Agent Engine, and Model Armor that shape runtime security decisions.
- The full MCP and OAuth 2.1 flow details, including dynamic client registration, PKCE, metadata discovery, and token validation.
- The practical explanation of how enterprise SSO, directory sync, and fine-grained authorization fit into B2B SaaS and agent workflows.
- The pricing and deployment distinctions that help teams decide where hosting, identity, and authorization responsibilities should sit.
👉 Read WorkOS's analysis of Google Vertex AI vs enterprise authentication →
Vertex AI vs WorkOS: where agent identity and auth really split?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Google Vertex AI and WorkOS split the agent identity stack