Skip to lesson

Google CloudProfessional Agentic Architect2026-090 Prerequisites

Separate identity from permission and delegation

Completed by the knowledge check

Learning objective

Distinguish authentication, authorization, delegation, workload identity, and identity propagation. This lesson establishes security vocabulary; later lessons apply specific Google Cloud agent identity and authorization controls.

Core idea

Ask five different questions at every hop:

  1. Authentication: Who or what proved an identity?
  2. Authorization: May that principal perform this action on this resource?
  3. Delegation: Did one principal grant a client limited authority to act?
  4. Workload identity: Which running software principal is making the call?
  5. Identity propagation: Which verified identity and delegation context must the next service receive?

Collapsing these questions creates confused-deputy and excessive-privilege failures. A valid credential proves something about identity; it does not grant every permission, and forwarding an identity does not automatically preserve the correct authority.

How it works

Authentication validates presented credentials and establishes a principal. The principal may be a person, workload, device, or service. Passwords, certificates, and signed tokens are credential mechanisms; they are not the principal itself.

Authorization evaluates a request using the authenticated principal, target resource, action, policy, and relevant context. In Google Cloud, Identity and Access Management (IAM) policies bind principals to roles, and roles contain permissions; see the IAM overview. Authentication can succeed while authorization denies the requested action.

Delegation lets a client act with authority granted by another principal, usually within a limited scope and time. OAuth 2.0 separates the resource owner, client, authorization server, and resource server. Its access tokens represent specific scopes and durations of access, as defined by RFC 6749. Delegation is not the same as sharing the user’s password, and the client does not become the user for every purpose.

Workload identity identifies running software independently of an end user. A workload might use an attached service account, a federated external identity, or another short-lived credential source. Google Cloud recommends Workload Identity Federation for external workloads so they can use federated, short-lived access rather than service account keys. The workload’s identity answers which software is calling, not which human requested the operation.

Identity propagation carries required security context across service or agent boundaries. Depending on the operation, a downstream service may need the workload principal, delegated end-user authority, or both. Each hop must validate the credential’s issuer, audience, lifetime, and intended use, then perform its own authorization check. Do not copy an unverified user ID from request data and treat it as authenticated identity.

Keep identities distinct in logs and policy decisions. Record the initiating user, the acting workload, the delegation mechanism, and the effective principal when available. This supports attribution without pretending that all four are the same entity.

Key distinctions and trade-offs

Authentication versus authorization: Authentication establishes identity. Authorization decides access. A signed token can be valid but lack the required scope, role, audience, or resource permission.

Delegated user access versus workload access: A calendar agent may need user delegation to read that user’s calendar. A nightly indexing job may act only as its workload identity. Using workload-wide privilege for a user-specific action can widen access beyond the user’s rights.

Impersonation versus delegation: Google Cloud service account impersonation lets an authenticated principal obtain short-lived credentials for a service account when granted the required permission. OAuth user delegation grants a client scoped access to a user’s resources. Both involve derived authority, but their principals and policy models differ.

Propagation versus credential forwarding: Propagation preserves necessary identity context. Blindly forwarding a bearer token can expose it to an unintended service or use it for the wrong audience. Token exchange or a service-specific credential can narrow authority at each hop.

Short-lived credentials reduce exposure and improve attribution, but require reliable issuance and renewal. Directly propagating user authority preserves least privilege for user-owned data, but not every backend accepts that form of identity. The architecture must make any fallback to workload authority explicit.

Architecture / decision scenario

An employee asks an expense agent to attach a receipt to a report. The front end authenticates the employee. The agent workload authenticates to the receipt service with its own workload identity and presents delegated user context scoped to expense access.

The receipt service validates both contexts. It authorizes the workload to call the API and verifies that the employee may modify the target report. The storage service receives a narrower service credential and a trusted report authorization decision; it does not trust an employee_id argument generated by the model.

If the agent used only its broad service identity, it could become a confused deputy and modify reports the employee cannot access. If it forwarded the user’s token to every backend, it could expose a bearer credential to unintended audiences.

Common exam traps

  • Treating successful authentication as permission to perform the action.
  • Treating an OAuth access token as proof that the client has every right of the user.
  • Using the end user’s identity and the agent workload’s identity as synonyms.
  • Passing a user ID in tool arguments and calling that identity propagation.
  • Forwarding one token through all services without checking audience or reducing privilege.
  • Assuming registration or discovery of an agent authorizes calls to it.

What to remember

  • Authentication identifies; authorization permits or denies.
  • Delegation grants limited authority without transferring every user privilege.
  • A workload needs its own identity even when acting for a user.
  • Validate and authorize identity context at every hop.
  • Preserve initiating, acting, delegated, and effective identities separately.

Knowledge check

References