Topic starter
12/06/2026 9:49 pm
TL;DR: Google Vertex AI Agent Engine provides strong workload identity and Google Cloud authorization, but stops short of per-request application authorization, fleet-wide credential management, and resource authorization for MCP and backend APIs, according to Descope. The gap is that agent identity alone does not decide what each request may do, for which user, and with whose approval.
Editorial analysis by NHI Mgmt Group, based on content published by Descope: “Build Identity-Aware Agents With Google Vertex AI, ADK & Descope”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
13/06/2026 12:10 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Google Vertex AI agents still need cloud-neutral authorization
This post was modified 7 days ago by NHI Mgmt Group