Skip to lesson

Google CloudProfessional Agentic Architect2026-095.1 Configuring agent security and governance

Delegate user access with Auth Manager

Completed by the knowledge check

Learning objective

Use Agent Identity Auth Manager for delegated end-user OAuth 2.0, and decide whether each tool call should act as the signed-in user or as the agent workload.

Core idea

Keep two authorities separate:

  • Workload authority belongs to the running agent. It proves which agent is calling and permits service-level work.
  • User-delegated authority comes from a specific user’s OAuth consent. It permits the agent to call a service on that user’s behalf, within the granted scopes and the service’s authorization rules.

Auth Manager connects these authorities without merging them. The workload uses its Agent Identity to authenticate to Auth Manager, and Identity and Access Management (IAM) controls whether it can use an auth provider. Three-legged OAuth (3LO) joins the end user, the client application, and the OAuth service. Auth Manager manages the resulting end-user token as delegated user authority. Google Cloud describes Auth Manager as both a centralized credential vault and an authentication broker for outbound tool calls in the Auth Manager overview.

Use this two-gate test:

may call as this user = workload may use the auth provider
                     AND user granted the required delegated authority

Passing the first gate does not give the workload the user’s external-service permissions. Passing the second does not let an arbitrary workload retrieve or use the stored token.

How it works

Create a 3LO auth provider with the external application’s client ID and secret, authorization endpoint, token endpoint, and dedicated redirect URI. Register that redirect URI with the external authorization server. Grant only the intended agent identity permission to retrieve credentials; the documented role is Agent Identity User (roles/agentidentity.user). See the 3LO configuration guide.

At runtime, the delegated flow follows these stages:

  1. The user requests an operation that needs access to the user’s external resource.
  2. If no suitable credential exists, the Agent Development Kit (ADK) emits an adk_request_credential function call. The client opens the authorization URL so that the user can sign in and consent.
  3. The client keeps the authorization request tied to the correct user and conversation. It records the consent nonce and related function-call state, validates the returning user, and finalizes the credential.
  4. Auth Manager exchanges the response and stores the OAuth tokens in a Google-managed credential vault.
  5. The client resumes the interrupted agent conversation. With the ADK integration, the agent retrieves the user’s token and injects it into the tool or Model Context Protocol (MCP) request header.
  6. The external service validates the token and authorizes the requested operation for the represented user and granted scopes.

The client-side step is part of the security boundary. A user ID supplied in a prompt is not proof of identity. Bind the consent nonce and callback state to an authenticated application session, especially when several consent flows can run at the same time. The Google Cloud guide specifies this consent-finalization and conversation-resume flow.

Request the minimum scopes needed for the tool, as recommended by OAuth 2.0 Security Best Current Practice. OAuth scopes limit what the token requests, while the external service’s resource policy decides which resources and actions the user can actually access. A scope is not a promise that every operation in that category succeeds.

Key distinctions and trade-offs

Acting as the user: Choose 3LO when the result must follow a person’s permissions, ownership, consent, or audit trail. Examples include reading that person’s GitHub repositories or updating that person’s Jira issues. Credential availability and revocation can vary by user.

Acting as the workload: Choose the agent’s own Agent Identity for Google Cloud services when the task belongs to the deployed agent. For an external service that supports machine-to-machine OAuth, use two-legged OAuth (2LO), also called the client credentials flow. It uses the agent’s authority and does not ask an end user for consent. The Agent Identity authentication models map these authorities to 3LO, Agent Identity, and 2LO.

Managed flow versus custom storage: Auth Manager handles token acquisition, storage, refresh, and ADK header injection. The application still owns user sessions, consent redirection, callback correlation, conversation resume, and failure behavior.

Convenience versus least privilege: A single broad provider and scope set is easy to reuse, but it increases the effect of a mistaken tool call or stolen token. Separate providers or scope sets by destination and privilege level, restrict which agent identities can retrieve from each provider, and require new consent when an operation needs broader authority.

Architecture / decision scenario

A support agent serves many employees. It performs two operations:

  1. It reads and comments on the signed-in employee’s private GitHub issues.
  2. It writes service-level metrics to a shared BigQuery dataset owned by the support platform.

The GitHub call must use a 3LO auth provider. The web client binds GitHub consent to the authenticated employee’s session, and Auth Manager stores that employee’s tokens. The ADK injects the delegated token only into the GitHub tool call. GitHub then limits the call by the employee’s access and granted scopes. If another employee starts a conversation, the agent must use that employee’s credential, not the first employee’s token.

The metrics write is not an employee action. The platform grants the agent’s own Agent Identity a narrow BigQuery role on the metrics dataset. The agent does not request employee consent or use an employee token. This supports scheduled work without bypassing GitHub’s per-user permissions.

If GitHub consent is missing or revoked, the agent pauses that operation and requests authorization again. It must not fall back to a broadly privileged workload credential, because that would change both the authority and the audit meaning of the action.

Common exam traps

  • Treating permission to use an auth provider as permission to access every resource available to the end user.
  • Using 2LO for a task whose result must reflect one user’s permissions and consent.
  • Requesting 3LO for service-owned scheduled work that has no user present.
  • Reusing one user’s stored credential for another user’s session.
  • Trusting a prompt, session parameter, or model-generated user ID instead of binding the callback to an authenticated client session.
  • Assuming Auth Manager removes the need for a client-side consent and conversation-resume flow.
  • Falling back from missing user consent to a more privileged workload credential.

What to remember

  • Use 3LO when the agent acts on behalf of a specific consenting user.
  • Use Agent Identity or 2LO when the agent acts with workload authority.
  • IAM access to an auth provider and external user authorization are separate gates.
  • Bind consent and stored credentials to the correct authenticated user and conversation.
  • Keep scopes, auth-provider access, and fallback behavior least-privileged.

Knowledge check

References