Section 5: Securing and governing agentic workflows

Question 1, 5.1 Configuring agent security and governance

A software company runs an ADK engineering assistant on Agent Runtime with Agent Identity enabled. Developers ask it to update their own Jira tickets, and Jira must record every change under the requesting developer's account. Security policy forbids storing user refresh tokens in application databases and requires that user consent can be reviewed and revoked centrally. The team also wants to avoid writing custom OAuth callback and token-refresh code. What should you do?

1. Create a 2-legged OAuth auth provider in Agent Identity auth manager with a Jira client ID and secret, and grant the agent identity access to it.
2. Create a 3-legged OAuth auth provider in Agent Identity auth manager, grant the agent identity Agent Identity User on it, and use it in the ADK tool.
3. Build a Cloud Run callback service that completes the Jira OAuth code exchange and stores each developer's refresh token in Firestore encrypted with CMEK.
4. Store a Jira API key for a shared integration user in Secret Manager and let the agent read it at startup through its agent identity.

Question 2, 5.1 Configuring agent security and governance

A bank runs five Agent Runtime agents under one shared service account whose JSON key is mounted in a sidecar. An audit found two issues: a developer impersonated the service account to run ad hoc BigQuery queries, and an access token copied from logs was replayed from a laptop. The bank plans to move each agent to Agent Identity. Which two properties of Agent Identity directly address these findings? (Choose two.)

1. Agent identities rotate their JSON keys every 24 hours, so a leaked key expires before it can be reused from another machine.
2. Agent identities are shared by all agents in a project by default, so one IAM binding covers the fleet and the sidecar can be removed.
3. Agent identities can't be impersonated, and developers can't generate long-lived service account keys for them.
4. Agent identities store their Google Cloud access tokens in auth manager, so tokens are never written to application logs.
5. Tokens are bound to each agent's X.509 certificate, and Context-Aware Access enforces mTLS and DPoP so they can't be replayed.

Question 3, 5.1 Configuring agent security and governance

After routing its Agent Runtime agents through an Agent-to-Anywhere Agent Gateway, a fintech company's compliance officer asks for a weekly report. For every denied request, it must show which MCP method and tool name the agent attempted and which Agent Registry resource the request matched. The team wants to use data that the gateway already produces instead of adding logging code to each agent. What should you do?

1. Query the reasoning_engine_stdout logs of each agent and parse the tool names that the ADK framework prints before every MCP call.
2. Export the attempted-authorization and authorization-failure scorecards and charts from the gateway's Observability dashboard each week.
3. Query the gateway_requests log of the Gateway monitored resource and report on its mcpInfo and agentRegistryResource fields.
4. Enable Model Armor in INSPECT_ONLY mode on the gateway and report on its sanitize operation logs, which record each tool request.

Question 4, 5.1 Configuring agent security and governance

A procurement agent on Agent Runtime calls a third-party inventory MCP server through an Agent-to-Anywhere Agent Gateway in the same project. The server exposes read-only lookup tools and several tools annotated as destructive. Governance requires that the agent can call the lookup tools, can never call destructive tools even if someone later adds a broader allow rule, and that rules target this specific server rather than a hostname pattern. Which two actions should you take? (Choose two.)

1. Reference the agent in the policy by its urn:agent identifier from Agent Registry so that the rule keeps following the agent across redeployments.
2. Register the MCP server in the regional Agent Registry instance that is associated with the gateway, in the gateway's project.
3. Write the allow rule on destination.unregistered.host with endsWith() so that it keeps working if the vendor adds new subdomains.
4. Attach a Model Armor template with the dangerous content filter set to HIGH so that destructive tool calls are blocked at the gateway.
5. Create a Unified Access Policy with an allow rule for the lookup tools and a deny rule for tools whose destructive_hint annotation is true.

Question 5, 5.2 Implementing secure agent behavior and execution

A bank deploys an ADK agent on Agent Runtime behind Agent Gateway. Requirements: incoming customer prompts must be screened for prompt injection; the agent's identity must be verified before any outbound call; and a plain-language rule must prevent the agent from initiating wire transfers above $10,000. Compliance edits that rule monthly and does not want code redeployments for each change. Which gateway configuration meets all requirements?

1. Client-to-Agent gateway: Model Armor and semantic governance CONTENT_AUTHZ policies. Agent-to-Anywhere gateway: an IAP REQUEST_AUTHZ policy.
2. Client-to-Agent gateway: a Model Armor CONTENT_AUTHZ policy. Agent-to-Anywhere gateway: IAP REQUEST_AUTHZ and semantic governance CONTENT_AUTHZ policies.
3. Agent-to-Anywhere gateway only: Model Armor and semantic governance CONTENT_AUTHZ policies, plus a before_tool_callback that checks the transfer limit.
4. Client-to-Agent gateway: an IAP REQUEST_AUTHZ and a semantic governance CONTENT_AUTHZ policy. Agent-to-Anywhere gateway: a Model Armor CONTENT_AUTHZ policy.

Question 6, 5.2 Implementing secure agent behavior and execution

An HR agent on Agent Runtime calls a user-scoped MCP server on behalf of employees. Credentials come from a 3-legged OAuth auth provider in Agent Identity auth manager, and outbound traffic goes through an Agent-to-Anywhere Agent Gateway with IAM policies on the agent identity. A security reviewer asks how authorization and audit attribution work for these delegated calls. Which two statements are correct? (Choose two.)

1. A call succeeds only if it satisfies both the agent's egress policies and the employee's own permissions and consented OAuth scopes.
2. Because a user token is attached, the gateway skips the agent's egress IAM policies and evaluates only the employee's own permissions.
3. If the employee lacks a permission that the agent identity holds, the call falls back to the agent's own authority and succeeds.
4. Audit logs for the call record both the agent's SPIFFE identity and the employee as the delegating user of the request.
5. Audit logs record only the employee's identity, because the agent presents an OAuth access token issued to that employee.