Google Vertex AI agents still need cloud-neutral authorization

At a glance

What this is: This is an analysis of Vertex AI agent identity and authorization gaps, with the central finding that workload attestation does not replace cloud-neutral per-request authorization.

Why it matters: IAM and NHI teams need to separate workload identity from decision-time authorization, or agent fleets will inherit permissions that are too coarse for user-scoped, tool-scoped, and tenant-scoped actions.

Context

Google Vertex AI Agent Engine gives agents a strongly attested identity, but the governance problem starts where that identity stops. The article argues that Google Cloud IAM can tell you which workload is calling, yet it does not decide whether a specific request should proceed for a specific user, tenant, or resource.

That gap matters because agent programs increasingly span more than one cloud, more than one runtime, and more than one downstream API. When authorization remains embedded in application code, teams inherit inconsistent decisions, unclear approval paths, and credential handling that is too local to the workload to govern centrally.

Key questions

Q: What breaks when agent identity is treated as enough authorization for Vertex AI workloads?

A: Per-request control breaks down because the runtime can prove who the agent is without proving what that request should be allowed to do. That leaves user scope, tenant boundaries, and resource entitlement to application code, which is too late for consistent governance.

Q: Why do agentic systems need token-issuance policy instead of only cloud IAM roles?

A: Cloud IAM roles are granted ahead of time and are usually too coarse for user-specific agent actions. Token-issuance policy can evaluate user, tenant, and requested scope together before access exists, which is the point where delegation should be constrained.

Q: How do security teams know if agent authorization is actually working?

A: Authorization is working only if the agent can complete the intended task without gaining unnecessary reach. Good signals include short-lived credentials, task-scoped permissions, approval for sensitive changes, and clear logs linking each action to a user and an agent. If credentials are reused, privileges persist, or the agent can move between systems without reauthorization, the control is failing.

Q: What is the difference between agent workload identity and delegated user authority?

A: Workload identity proves which agent instance is acting, while delegated user authority determines what that agent may do on behalf of a person or tenant. The first is runtime attestation, the second is business authorization, and they should never be collapsed into one control.

Technical breakdown

Workload identity does not equal request authorization

Vertex AI Agent Engine uses attested workload identity, including SPIFFE-based credentials bound to the runtime. That is a strong control for proving that the caller is the expected agent instance, and it reduces impersonation risk inside Google Cloud. But workload identity only answers who is speaking. It does not answer whether the request should be allowed, which scopes should be issued, or whether the invoking user is entitled to that action. In identity terms, the runtime proves the actor, while the application still has to decide the transaction. Practical implication: separate workload attestation from per-request authorization, and do not treat one as a substitute for the other.

Practical implication: keep workload identity and request-level authorization as separate control layers.

Why cloud IAM is too coarse for agent-scoped decisions

Google Cloud IAM grants roles to identities ahead of time, which works for infrastructure permissions but not for fine-grained agent decisions. The article’s point is that an analyst using an agent should not automatically inherit every permission that the agent or service account can reach. The missing layer is issuance-time policy that evaluates the requesting user, tenant, and scope before a token exists. That is a different control objective from cloud role assignment. Practical implication: move user-specific decisioning into token issuance and resource authorization, rather than encoding it in application logic after the fact.

Practical implication: enforce user and tenant conditions at issuance time, not after token minting.

MCP and backend APIs need their own authorization server

Model Context Protocol environments introduce a resource authorization problem that identity platform sign-in alone does not solve. The article notes that Google Identity Platform can authenticate users, but it is not an authorization server for MCP clients, backend APIs, consent, scope issuance, or dynamic client registration. That means the application still needs a protocol layer that can register clients, issue scoped tokens, and support step-up or backchannel approval when a tool action is sensitive. Practical implication: treat MCP and API access as first-class authorization surfaces, not as a side effect of user login.

Practical implication: put OAuth-based authorization in front of MCP servers and backend APIs.

NHI Mgmt Group analysis

Per-request authorization has become the missing control plane for agentic systems: the article shows that strong workload identity does not resolve the decision of what an agent may do on a specific request. Google Cloud IAM can attest the workload, but application code still owns user-scoped, tenant-scoped, and scope-scoped decisions. The implication is that agent identity programmes must stop treating runtime identity as the end state and start treating it as one input to a broader authorization model.

Cloud-neutral authorization is now a governance requirement, not a convenience layer: the article describes a fleet that spans multiple runtimes and cloud environments, while the native control path remains tied to one cloud control plane. That creates fragmented governance if per-user decisions are left inside each app or tool. The implication is that identity teams need a consistent policy and credential boundary that survives workload mobility across clouds and agent frameworks.

Runtime identity and delegated authority are different security problems: the agent can be strongly identified and still be over-authorized for the user who invoked it. That distinction matters for AI agents because the trust decision is no longer only about the workload, but about the delegation chain behind it. The implication is that governance must evaluate who delegated what, to which agent, for which resource, before the agent acts.

Issuance-time policy is the right control point for agent delegation: the article’s architecture pushes decision-making to the moment a token is minted, rather than relying on later checks in the tool or API path. That model is materially stronger than static role assignment for agent workflows because it can incorporate user, tenant, and scope context together. The implication is that teams should move from static role grants to token-issuance governance when agent actions affect business systems.

Context-rich logging becomes essential once agents mediate human intent: the article distinguishes between logging that records a call and logging that records the policy inputs behind a denied or approved scope. That is the difference between a traffic log and an auditable decision record. The implication is that organisations need logs that preserve user, role, tenant, and approval context for agent-mediated actions, or they lose the ability to explain why a request was allowed.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Authorisation Guide

What this signals

Per-request authorization is the real boundary for agent governance: once agents can act across MCP servers, backend APIs, and multiple clouds, a single cloud IAM model no longer describes the decision that matters. The programme question becomes whether issuance-time policy can stay consistent as agent fleets move across runtimes and tenants.

Cloud-neutral policy reduces delegation drift: when the same agent can operate on Google Cloud, another cloud, and local development environments, the safest control is the one that travels with the token, not the one tied to a platform account. That shifts identity teams toward centralised issuance and away from app-by-app permission logic.

Runtime attestation is necessary but not sufficient for AI agent security: an attested workload can still be over-entitled for the user behind it. Teams should prepare for a split control model where attestation proves execution integrity and authorization proves request legitimacy.

For practitioners

• Separate workload identity from request authorization Treat attested runtime identity as proof of who the agent is, then apply an independent policy layer for what each request may do.
• Move user-scoped decisions to token issuance Evaluate user role, tenant, and requested scope before minting access tokens, so the application does not decide permissions after the fact.
• Front MCP servers with OAuth authorization Require client registration, scope issuance, and consent handling in front of MCP servers and backend APIs instead of relying on sign-in alone.
• Use vaulted credentials for agent tool calls Replace hardcoded API keys and tokens in tools with retrieval from a central credential vault so secrets never live inside the agent environment.
• Record approval context with delegated actions Log the user, tenant, roles, granted scopes, refused scopes, and any approval event together so agent decisions remain auditable across the fleet.

Key takeaways

• Vertex AI agent identity proves the workload, but request authorization still has to decide what the agent may do, for whom, and in which tenant.
• Cloud IAM alone is too coarse for agentic workflows that need scope-aware, user-aware decisions at issuance time.
• A central authorization layer, plus vaulted credentials and auditable approval context, is the control pattern this article argues for.

Key terms

• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
• Issuance-time policy: Issuance-time policy is the practice of evaluating who is asking, what they may request, and which scopes are allowed before a token is minted. For agents, this is the control point that prevents excess privilege from ever becoming an active credential.
• Cloud-Neutral Authorization: An authorization model that is not tied to one cloud provider’s IAM plane. It allows the same policy logic to govern agent requests across multiple runtimes, APIs, and resource types, which is essential when fleets span clouds.
• Delegated Authority Model: A delegated authority model defines who is allowed to approve, review, or execute control-related decisions across the enterprise. It helps ensure requests reach the correct responsible party, especially when control owners, managers, and process owners sit in different teams, regions, or systems.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.