Google Vertex AI and WorkOS split the agent identity stack

At a glance

What this is: This is a layer-separation analysis showing that Vertex AI governs agent runtime inside Google Cloud, while WorkOS handles enterprise authentication, authorization, directory sync and MCP OAuth for customer-facing applications.

Why it matters: IAM and identity teams need to separate workload control from customer trust boundaries, because agent hosting, enterprise SSO, lifecycle management and tool authorization fail differently and belong to different control planes.

Context

Agent identity does not collapse into a single control plane just because the same system hosts models, tools and runtime orchestration. In B2B AI systems, the governance question is where trust is enforced for the workload, where it is enforced for the customer, and where those boundaries must stay separate.

WorkOS frames Google Vertex AI and WorkOS as complementary layers rather than substitutes: Vertex AI governs agent execution inside Google Cloud, while WorkOS governs enterprise identity, authorization and MCP access across customer environments. That split matters because lifecycle, federation and fine-grained permissions are not solved by runtime hosting alone.

For IAM and NHI programmes, this is a useful reminder that the identity model changes with the boundary being controlled. A cloud-perimeter identity story is not the same as a customer-facing enterprise auth story, even when the same agent is involved.

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. If both are merged into one layer, offboarding and tenant isolation become ambiguous. Separate ownership, separate policies and separate audit expectations are the safer model.

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. That difference matters because MCP tools are called on behalf of users or delegated actors. With shared keys, access control and attribution both degrade, and policy enforcement becomes far harder to trust.

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. Without SSO, each enterprise may demand a separate login pattern, and without SCIM, identity changes do not flow cleanly into the tenant model. That creates access drift, weak accountability and a gap between the customer’s directory and the application’s permission state.

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.

Technical breakdown

Agent runtime identity inside Google Cloud

Vertex AI ties agent identity to Google Cloud IAM, service accounts and VPC-scoped controls. That means access is enforced where the agent runs, with perimeter controls such as VPC Service Controls, Private Service Connect and CMEK shaping data movement and key use. The model is suited to workloads whose execution, storage and observability all remain inside the same cloud boundary. It does not create an enterprise identity layer for external tenants or customer-managed federation; it secures the runtime environment, not the business relationship around it.

Practical implication: treat cloud-native agent identity as a workload control layer, not as a substitute for customer authentication and authorization.

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

WorkOS is positioned as the customer identity and authorization layer for applications that must integrate with external IdPs. SSO via SAML and OIDC, SCIM provisioning, audit logs and fine-grained authorization address who the customer is, how lifecycle events are synchronized and how permissions are expressed per tenant or resource. This is the layer that normalizes identity across Okta, Entra ID and other enterprise directories. Without it, an AI application may run securely but still fail enterprise onboarding, offboarding and access governance requirements.

Practical implication: use a separate identity control plane for customer federation, provisioning and authorization when your product serves external enterprises.

OAuth 2.1 for MCP servers and agents

MCP changes the identity problem because tools and agents need explicit authorization to call protected resources. An OAuth 2.1 authorization server for MCP provides discovery metadata, dynamic client registration, PKCE and JWT validation so tool access is granted through standard flows rather than embedded secrets. That is a different control surface from cloud IAM because the target is the tool endpoint and the client is often an agent or MCP consumer outside the host cloud. This is where token issuance, scope design and resource metadata become the governance boundary.

Practical implication: front MCP tools with standards-based OAuth rather than treating tool access as an internal-only runtime permission.

Threat narrative

Attacker objective: The objective is to use an agent or MCP path to reach enterprise data and actions without respecting the separate identity boundary that should govern customer access.

1. Entry begins when an agent or MCP client reaches a protected tool or API through a standard connection path that still requires explicit authorization.
2. Credential access occurs through token issuance, delegated scopes or enterprise SSO assertions rather than through direct cloud runtime credentials.
3. Escalation happens when broad runtime access is mistaken for customer authorization, allowing tool calls beyond the intended tenant or resource boundary.
4. Impact is unauthorized access to enterprise systems, data or actions through an agent path that was trusted for execution but not properly bounded for identity.

Breaches seen in the wild

• Google API Keys Exposure — Gemini AI: Google API keys exposed in client-side code via Gemini AI integrations, creating data leak risk.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

The identity stack for B2B AI splits at the boundary between workload control and delegated customer trust. That split is now visible in MCP, where tool access needs explicit OAuth 2.1 semantics rather than implicit runtime trust. The lesson for identity programmes is that the same agent may require one control plane for workload access and another for tenant-facing authorization.

Ephemeral runtime trust and durable customer identity cannot be governed by the same lifecycle assumptions. Provisioning an agent inside a cloud account does not solve onboarding, offboarding or per-customer permissioning across external IdPs. The implication is that lifecycle governance must be modelled separately for the workload executor and for the enterprise user or tenant authorizing it.

Workload observability is not identity governance. Token usage, latency and tool-call traces tell you what the agent did, but they do not establish whether the right tenant, the right client or the right scope was authorized. Teams should treat telemetry as evidence of activity, not as proof of delegated access correctness.

Identity architecture for AI will increasingly be layered, not monolithic. Google Cloud-native controls will continue to secure runtime, while external authorization products will carry enterprise federation and fine-grained app permissions. The practical conclusion is that programme owners should map where each trust decision is enforced before deciding which control family owns it.

From our research library:

• 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.

What this signals

Identity separation is becoming the default pattern for serious AI applications. The agent runtime will increasingly live behind cloud-native controls, while enterprise trust, provisioning and resource authorization will live in a separate federation layer. Teams that do not model this split will keep overloading IAM with responsibilities it was never designed to absorb.

Tool access is now an authorization problem, not just an integration problem. MCP and similar protocols move AI systems toward explicit consent, scoped tokens and client registration, which means secrets management alone is no longer enough. The governance question is whether each tool call is bound to a clearly defined tenant, client and purpose.

Agent runtime identity and enterprise identity are different governance problems. That distinction will matter more as organisations connect more tools, more customer directories and more autonomous workflows to the same agent stack.

For practitioners

• 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. Do not let cloud IAM stand in for enterprise federation or app authorization.
• 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.
• Use fine-grained authorization for tenant resources Apply resource-level policy for document, project or tool access so enterprise customers can express least privilege independently of where the agent runs.

Key takeaways

• 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.
• MCP pushes identity governance toward explicit token boundaries, which makes OAuth-based access control more important than hidden trust in agent internals.
• IAM teams need separate control models for workload execution, enterprise federation and fine-grained resource access if they want to avoid privilege drift in B2B AI systems.

Key terms

• AI Agent Runtime Identity: AI Agent Runtime Identity is the identity an AI agent uses while it is actively running and making decisions. It covers the credentials, permissions, and trust signals tied to that execution session, so actions can be attributed, constrained, and audited. It often changes by task, context, or policy.
• Enterprise Federation: Enterprise federation is a trust model that allows identities from one organisation or directory to authenticate into another using established trust relationships. In M&A, it can help bridge two environments during transition while reducing the need for immediate account duplication or re-creation.
• MCP authorization: MCP authorization is the control layer that decides whether an agent or client may use a specific tool in a specific context. In secure deployments, it must go beyond token claims and incorporate user identity, resource ownership, and policy at request time.
• Fine-Grained Authorization: Fine-grained authorization is access control that evaluates specific resources, actions, and context rather than granting broad application-level permission. For AI agents, this is the difference between merely connecting to a system and being limited to the exact data or action the task requires.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.