Topic starter
07/06/2026 8:58 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “Google Vertex AI vs. WorkOS: ML Platform Meets Enterprise Authentication”.
Key questions
Q: How should teams separate agent runtime IAM from enterprise customer access?
A: Treat cloud IAM as the control for where the agent can execute, and treat federation, SCIM and app authorization as the control for who the customer is and what they can reach.
Q: Why do MCP servers need OAuth and OIDC instead of a shared API key?
A: OAuth and OIDC let the server issue and validate identity-bound tokens, while a shared API key collapses every caller into the same credential.
Q: What breaks when enterprise SSO and SCIM are missing from an AI product?
A: Customer onboarding and offboarding become manual, inconsistent and hard to audit.
Practitioner guidance
- Separate runtime IAM from customer authorization Document which controls secure the agent execution environment and which controls secure tenant login, directory sync and resource-level permissions.
- Model MCP access as a token-governed trust boundary Require OAuth 2.1, PKCE, dynamic client registration and scope validation for MCP-facing tools instead of embedding static credentials in agent workflows.
- Map lifecycle ownership for agents and tenants separately Define who provisions, reviews and offboards agent identities inside the cloud runtime and who owns customer SCIM, SSO and authorization lifecycle in the SaaS layer.
Bottom line: Vertex AI and WorkOS sit at different layers of the agent stack, with one focused on runtime control in Google Cloud and the other on customer identity, authorization and lifecycle management.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
08/06/2026 8:43 am
Agent runtime identity and enterprise identity are different governance problems. Vertex AI can bind agents to Google Cloud IAM, but that only governs execution inside a cloud boundary. Enterprise SSO, SCIM and per-tenant authorization remain separate because they answer who the customer is, not where the agent runs. Practitioners should stop treating agent hosting and customer trust as a single control decision.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What is the difference between workload identity and agentic identity?
A: Workload identity assumes a deterministic system that performs known machine tasks with stable permissions. Agentic identity adds autonomy, context switching, and the possibility that one agent will use both delegated and machine credentials. The difference matters because the second model requires runtime authorization and stronger audit evidence, not just secret management.
👉 Read our full editorial: Google Vertex AI and WorkOS split the agent identity stack
This post was modified 3 days ago by NHI Mgmt Group