Notifications
Clear all
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.
NHIMG editorial — based on content published by Descope: Build identity-aware agents with Google Vertex AI, ADK and Descope
Questions worth separating out
Q: How should security teams govern AI agents that call multiple APIs and MCP servers?
A: They should separate runtime identity, application authorisation, and credential retrieval into distinct controls.
Q: Why is cloud IAM alone not enough for agentic workloads?
A: Cloud IAM only governs what a workload may do inside a cloud control plane.
Q: What breaks when agent credentials are stored only in the runtime environment?
A: Long-lived secrets become available to any tool path, prompt leak, or misconfigured connector that can reach the runtime.
Practitioner guidance
- Map the control boundary before deploying agents Document which decisions are handled by cloud IAM, which are handled by application scopes, and which are handled by approval workflows before any production rollout.
- Remove static secrets from agent tool paths Replace hardcoded API keys and long-lived tokens with a vault-backed exchange pattern so tools fetch scoped credentials only when policy allows.
- Issue scopes at the moment of use Evaluate user, tenant, agent, and requested scope together at token issuance so the agent cannot request broader access than the invoking identity already holds.
What's in the full article
Descope's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step Vertex AI and Descope integration flow for user authentication, token exchange, and agent session setup
- Code examples for fetching scoped credentials from a vault during tool execution instead of embedding secrets in the runtime
- CIBA and step-up approval mechanics for sensitive actions that need out-of-band human confirmation
- Configuration walkthroughs for MCP Auth, Resources, Connections, and per-tenant SSO setup
👉 Read Descope's analysis of cloud-neutral authorization for Vertex AI agents →
Why Vertex AI agents still need cloud-neutral authorization?
Explore further
13/06/2026 12:10 am
Cloud-attested agent identity does not equal governed agent authority. Vertex AI’s SPIFFE-based attestation answers the question of whether the agent is authentic inside Google Cloud, but not the question of whether the agent should be allowed to act for a specific user or resource. That matters because identity proof and authorisation are not interchangeable control layers. Practitioners should resist treating runtime attestation as a complete governance model for agentic access.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable for delegated access decisions in agent workflows?
A: Accountability should rest on the system that issues the scope, the approver if one is involved, and the team operating the policy. Logging the agent’s action alone is not enough because it does not explain why the privilege existed. Teams need records that link the user, tenant, approval, and granted scope.
👉 Read our full editorial: Google Vertex AI agents still need cloud-neutral authorization
