Book TOC · Previous · Chapter 7 of 8 · Next

Chapter 7: Securing & Governing Agentic Systems: OAuth 2.0, PAB, Model Armor, Guardrails & HITL

Official Exam Guide Subsections Consolidated: 5.1, 5.2

Chapter Consolidation Telemetry: Synthesizes 64 architectural scenarios across 2 Exam Subsections and 6 Official Considerations into consolidated takeaway pillars, paired with 2 Reference Architecture Mermaid Diagrams and 16 Curated Visual Illustrations.

Chapter Focus: Principal Access Boundary (PAB), Agent Gateway, Model Armor (prompt injection/jailbreak defense), deterministic Confirmation Gates, HITL, and SDP/DLP redaction.

Subsection 5.1: Securing agentic systems

Section 5: Securing and Governing Agentic Systems (15%) · 4 Official Considerations · 37 Scenarios Consolidated

Domain Overview and Reference Architecture

Zero-Trust Architecture for Autonomous Agents

An autonomous agent connected to enterprise APIs and databases introduces a high-stakes security challenge: unlike traditional microservices with hardcoded call graphs, an agent dynamically chooses which tools to invoke based on untrusted inputs. If an agent uses over-privileged static credentials, lacks an identity boundary, or bypasses centralized traffic inspection, a single Indirect Prompt Injection or misconfigured tool can trigger catastrophic data exfiltration.

Section 5.1 of the PAA exam tests four interlocking pillars of agent security:

1. Secure Tool Execution with OAuth 2.0 (5.1a): Using Auth Manager (OAuth 2.0) and short-lived tokens for agent-to-tool API calls instead of static keys or shared admin credentials.
2. Principal Access Boundary (PAB) Policies (5.1b): Binding identity-centric PAB policies to Agent Identity so a principal can never access resources outside its approved perimeter—even if granted an overly broad IAM role elsewhere.
3. Traffic Monitoring & Tracking via Agent Gateway (5.1c): Routing agent-to-tool and agent-to-agent traffic through Agent Gateway for centralized visibility, rate limiting, and anomaly detection.
4. Governance & Policy Enforcement (5.1d): Combining Agent Registry (approved catalog & lifecycle governance) with Model Armor (runtime defense against prompt injection, jailbreaks, and sensitive data leaks).

Exam Scope Covered in This Chapter

• 5.1a Implementing Authentication and Secure Tool Execution: Securing agent-to-tool API calls using Auth Manager (OAuth 2.0) (Authorization Code / On-Behalf-Of for user-delegated actions, Client Credentials / Workload Identity for machine-to-machine calls) with short-lived, narrowly scoped tokens.
• 5.1b Configuring Principal Access Boundary (PAB) Policies Using Agent Identity: Enforcing an identity-centric ceiling on the resources a dedicated Agent Identity can ever access across Google Cloud projects and folders.
• 5.1c Configuring Agent Gateway to Monitor Traffic and Track Agents: Centralizing ingress/egress telemetry, agent lineage tracking, rate limiting, and quota enforcement across distributed agent fleets.
• 5.1d Designing and Configuring Agentic Governance and Policy Enforcement: Preventing "Shadow AI" via Agent Registry and blocking adversarial prompt injections/jailbreaks via Model Armor.

Core Foundational Primitives & Mental Models (Subsection 5.1)

Official Exam Considerations & Consolidated Takeaways (Subsection 5.1)

Consideration 5.1a: Implementing authentication and secure tool execution (e.g., agent-to-tool api calls using oauth 2.0)

When designing authentication for agent-to-tool API calls:

• Never Use Static Keys: Reject any option that stores static Service Account JSON keys (key.json), long-lived API tokens in environment variables, or credentials inside system prompts.
• User-Delegated Actions (OAuth 2.0 Authorization Code / On-Behalf-Of Token Exchange): When a human user asks an agent to act on their behalf (e.g., querying their personal Salesforce pipeline, reading their Gmail/Drive, or submitting an HR request), use Auth Manager (OAuth 2.0) to exchange the user's identity token for a short-lived, least-privilege OAuth 2.0 access token scoped strictly to that user's permissions.
• Autonomous Background Execution (OAuth 2.0 Client Credentials / Workload Identity): When an agent runs on a schedule or processes system events without a human user in the loop, authenticate using its dedicated Agent Identity via Workload Identity Federation or OAuth 2.0 Client Credentials with minimum required scopes.

Takeaway 1: OAuth 2.0 Client Credentials for Internal Service Calls (vertex_ai:agent_builder · cloud_run · iam)

• Core Concept: Machine-to-machine authentication using OAuth 2.0 Client Credentials and Google-managed service account identity tokens for Cloud Run tools.
• Scenario Trigger & Requirement: Three essential constraints: an automated AI agent calling an internal Cloud Run microservice, machine-to-machine execution requiring no end-user intervention, and the requirement for short-lived secure credentials according to Google Cloud best practices.
• Winning Architecture & Implementation: Configure the agent tool to generate OpenID Connect (OIDC) ID tokens for a dedicated service account, and grant that service account the Cloud Run Invoker role on the microservice. Google Cloud Run authenticates private incoming requests by validating Google-signed OpenID Connect (OIDC) ID tokens passed in the Authorization: Bearer ID_TOKEN header.
• Exam Traps to Reject: API keys do not authenticate service identities on private Cloud Run services and are long-lived static secrets. The Authorization Code grant requires interactive human consent and is unsuitable for autonomous machine-to-machine calls.

Takeaway 2: On-Behalf-Of Delegation via OAuth 2.0 Token Exchange (iam:oauth · iam:service_accounts · vertex_ai:agents)

• Core Concept: Propagating end-user identity to tool APIs via RFC 8693 Token Exchange to maintain user-level access controls.
• Scenario Trigger & Requirement: The scenario requires an AI agent to query an external protected API on behalf of an authenticated user. Key requirements include preserving the patient's individual identity, respecting granular user consent, and avoiding shared or over-privileged service accounts.
• Winning Architecture & Implementation: Implement OAuth 2.0 Token Exchange (RFC 8693) to exchange the incoming user identity token for a downscoped tool access token. OAuth 2.0 Token Exchange (RFC 8693) enables an application or AI agent to exchange an existing security token (such as the end user's incoming identity token) for a new access token tailored specifically for a target tool or API.
• Exam Traps to Reject: A shared service account bypasses user-level access controls and grants excessive privileges. Collecting passwords in chat creates severe security vulnerabilities and violates credential management standards.

Takeaway 3: Cross-Cloud Tool Execution via Workload Identity Federation (iam:workload_identity · security:iam)

• Core Concept: Accessing third-party cloud tools without persistent credentials using Workload Identity Federation.
• Scenario Trigger & Requirement: An agent running in Google Cloud that needs to execute an external tool in AWS (AWS Lambda). The key technical constraint is the strict prohibition of long-lived, static access keys anywhere in the environment. You must select the native, identity-federated mechanism that enables cross-cloud tool execution securely.
• Winning Architecture & Implementation: Configure an AWS Identity and Access Management (IAM) role with OpenID Connect (OIDC) trust for Google Cloud, and let the agent exchange Google Cloud tokens for temporary AWS Security Token Service (STS) tokens. Configuring OpenID Connect (OIDC) federation between Google Cloud and AWS IAM allows workloads to exchange short-lived Google Cloud identity tokens for temporary AWS Security Token Service (STS) credentials.
• Exam Traps to Reject: Storing static keys in Secret Manager violates the requirement to avoid long-lived credentials. GCP service account keys cannot be imported as AWS IAM users and represent long-lived credentials.

Consolidated Golden Rules (Consideration 5.1a):

• Machine-to-machine authentication between agents and private Cloud Run tools requires service account OpenID Connect (OIDC) ID tokens.
• Grant the roles/run.invoker role to the caller service account on the destination Cloud Run resource.
• Avoid static API keys and user-interactive authorization flows for automated backend tool execution.
• Always propagate end-user identity using token exchange patterns when tools access user-specific resources.
• Avoid shared service credentials or static keys for multi-user transactional workflows.
• OAuth 2.0 Token Exchange (RFC 8693) supports the principle of least privilege by producing downscoped tokens.

Consideration 5.1b: Configuring principal access boundary (pab) policies using agent identity

Understand why Principal Access Boundary (PAB) is a favorite exam topic:

• How PAB Works Together with IAM: Standard IAM policies grant permissions (what a principal can do). A Principal Access Boundary (PAB) policy bound to an Agent Identity defines the eligible resource boundary (where that principal is allowed to operate, such as a specific Google Cloud folder or project).
• Effective Access = IAM Grant ∩ PAB Eligible Resources: Even if a project admin in another department accidentally grants your agent roles/owner or roles/bigquery.admin on their project, the PAB policy blocks the access deterministically because that target project is outside the agent's Principal Access Boundary!
• PAB vs. VPC Service Controls (VPC-SC): Remember: PAB is bound to the Principal (Agent Identity) to restrict which resources that identity can touch; VPC-SC is a Network/Service Perimeter around resources to prevent data exfiltration.

Takeaway 1: Preventing Agent Cloud Storage Data Exfiltration Across Folders (iam:principal_access_boundary · iam:service_accounts · storage:buckets)

• Core Concept: Restricting principal resource reach to dedicated bucket scopes using Principal Access Boundary (PAB) rules
• Scenario Trigger & Requirement: The scenario requires restricting an AI agent runtime service account from accessing Cloud Storage buckets outside a specific folder, while keeping its existing project-level IAM roles intact. The key requirement is enforcing a strict resource reach limit directly on the agent identity.
• Winning Architecture & Implementation: Create a Principal Access Boundary policy that defines the designated folder as the allowed resource boundary, and bind the policy to the agent service account. Principal Access Boundary (PAB) policies define a boundary of Google Cloud resources that a principal can access. When you bind a PAB policy to a principal, such as an AI agent service account, the principal cannot access any resources outside that boundary, even if broader IAM roles exist.
• Exam Traps to Reject: Organization Policies apply guardrails to resource hierarchy nodes rather than individual principal identities. VPC Service Controls enforces network-level perimeters for projects rather than identity-scoped resource boundaries.

Takeaway 2: Agent Token Impersonation and Downstream Resource Scoping (iam:pab · iam:service_accounts · bigquery)

• Core Concept: PAB policy enforcement during Workload Identity and Service Account token impersonation
• Scenario Trigger & Requirement: An AI agent running in a sandbox environment that performs service account impersonation to obtain temporary credentials.
• Winning Architecture & Implementation: Attach a Principal Access Boundary policy to the agent principal identity that restricts accessible resources to non-finance folders. A Principal Access Boundary (PAB) policy creates an explicit ceiling on the resources that a principal can access. When attached to the agent principal identity, any short-lived credentials or impersonated tokens generated for that identity automatically inherit the boundary restrictions.
• Exam Traps to Reject: Modifying central service account permissions breaks other workloads and creates massive management overhead. VPC Service Controls protect network perimeters and cannot enforce token-scoping boundaries on principal identities.

Takeaway 3: Detecting and Auditing PAB Policy Violations in Agentic Tool Execution (iam:access_boundary · cloud_logging:audit_logs · artifact_registry)

• Core Concept: Cloud Audit Logging and diagnostic evaluation of denied actions caused by PAB enforcement
• Scenario Trigger & Requirement: A scenario where an autonomous agent possessing valid IAM roles receives a permission denied error when attempting to query Artifact Registry. You need to troubleshoot and verify if the denial is caused by a Principal Access Boundary (PAB) policy.
• Winning Architecture & Implementation: Review Cloud Audit Logs in Cloud Logging and inspect the authorization info section for policy denial details containing the Principal Access Boundary policy identifier. When a Principal Access Boundary (PAB) policy blocks a principal from accessing a resource, Google Cloud logs the access attempt in Cloud Audit Logs.
• Exam Traps to Reject: Policy Analyzer evaluates effective IAM role bindings rather than real-time audit logs of PAB policy enforcement. VPC Service Controls logs track network perimeter violations rather than Principal Access Boundary identity policies.

Takeaway 4: Enforcing Multi-Tenant Agent Isolation within a Single Project (iam:pab · spanner · resource_manager:tags)

• Core Concept: Condition-based PAB policies targeting specific Resource Manager tags or prefix paths
• Scenario Trigger & Requirement: The scenario requires restricting a specific agent (the HR Agent service account) so that it can only access Cloud Spanner databases carrying a specific HR tag. Both agents reside in the same project, meaning project-level network isolation (such as VPC Service Controls) cannot separate them.
• Winning Architecture & Implementation: Create a Principal Access Boundary policy with a resource rule matching the HR Resource Manager tag, and bind the policy to the HR Agent service account. Principal Access Boundary (PAB) policies establish explicit resource guardrails on identities (such as service accounts).
• Exam Traps to Reject: VPC Service Controls isolates projects at the perimeter level rather than separating resources within the same project by tag. IAM conditions with auth claims do not enforce an organization-wide principal access boundary on service accounts.

Consolidated Golden Rules (Consideration 5.1b):

• Principal Access Boundary (PAB) policies enforce identity-level guardrails that restrict the resources a principal can access.
• PAB policies override broader IAM permissions without requiring you to rewrite existing role bindings.
• Organization policies govern resource hierarchy nodes, whereas PAB policies govern individual principal identities.
• Principal Access Boundary (PAB) policies enforce an explicit ceiling on the resources that a principal can interact with.
• PAB policies carry over to short-lived credentials and tokens minted during service account impersonation.
• Using PAB policies allows enterprises to safely share high-privilege service accounts without exposing sensitive organizational folders to sandboxed agents.

Consideration 5.1c: Configuring agent gateway to monitor traffic and track agents

When governing live agent network traffic across the enterprise:

• Agent Gateway as the Centralized Inline Proxy: Instead of letting 50 agents make direct point-to-point HTTP calls to 100 internal and third-party MCP servers, route all agent traffic through Agent Gateway.
• Capabilities of Agent Gateway:
• Centralized Traffic Monitoring & Lineage Tracking: Records every agent-to-tool and agent-to-agent invocation with caller Agent Identity, target tool version, latency, and token metrics.
• Rate Limiting & Quota Enforcement: Protects fragile downstream backends (like legacy ERPs) from runaway agent loops.
• Centralized Circuit Breaking / Revocation: Allows security operations to immediately block traffic from a compromised agent or to a vulnerable MCP server at the gateway without redeploying agent code.

Takeaway 1: End-to-End Distributed Tracing Across Multi-Agent Handoffs (cloud_run · cloud_trace · cloud_logging · vertex_ai:agents)

• Core Concept: W3C Trace Context propagation across heterogeneous agent calls
• Scenario Trigger & Requirement: A multi-agent system where a supervisor agent coordinates downstream sub-agents hosted on Cloud Run. When timeouts occur across multiple hops, developers lack visibility into which specific sub-agent or tool call is taking too long. The primary requirement is enabling distributed tracing across these heterogeneous agent interactions.
• Winning Architecture & Implementation: Configure the Agent Gateway to inject and propagate W3C Trace Context headers across all downstream agent requests, and export traces to Cloud Trace. Configuring the Agent Gateway to inject and propagate standard W3C Trace Context headers (such as traceparent and tracestate) ensures that every downstream agent and tool invocation shares the same trace identifier.
• Exam Traps to Reject: Cloud Armor focuses on DDoS and web application security, not multi-agent trace diagnostics. Log-based metrics aggregate counts but fail to provide correlated latency graphs across distributed agent hops.

Takeaway 2: Granular Rate Limiting for Autonomous Tool Execution (apigee · vertex_ai:agents · api_gateway)

• Core Concept: Tool execution rate limiting to mitigate denial-of-wallet and infinite looping
• Scenario Trigger & Requirement: An autonomous AI agent entering an infinite recursive loop, rapidly firing thousands of requests to an external paid API tool. The primary requirements are halting runaway execution ('denial-of-wallet' attacks or software defects) and allowing normal operational bursts without shutting down the entire agent workflow.
• Winning Architecture & Implementation: Configure token bucket rate limiting and concurrency limits on the API gateway keyed by agent ID and target tool endpoint. Configuring token bucket rate limiting and concurrency limits on the API gateway layer provides granular traffic control.
• Exam Traps to Reject: IP address filtering controls network reachability, not transaction rates or recursive calling patterns. Batch log processing is too slow to stop real-time recursive execution and disrupts unrelated operations.

Takeaway 3: Mutual TLS and Zero-Trust Agent-to-Tool Authentication (cloud_service_mesh · iam:workload_identity · vertex_ai:agents)

• Core Concept: Cryptographic workload identity verification for backend agent integrations
• Scenario Trigger & Requirement: The scenario requires securing agent-to-backend microservice communications. Key constraints are: 1) Cryptographically verify calling agent identity on every tool invocation, 2) Avoid storing static API keys or long-lived credentials in configurations, and 3) Monitor and track agent traffic via an Agent Gateway.
• Winning Architecture & Implementation: Configure mutual Transport Layer Security (mTLS) on the Agent Gateway and issue short-lived X.509 certificates through Workload Identity. Configuring mutual Transport Layer Security (mTLS) with short-lived X.509 certificates issued via Workload Identity allows backend services and the Agent Gateway to verify caller identities cryptographically.
• Exam Traps to Reject: Long-lived tokens in Secret Manager create security risks and do not provide cryptographic mutual transport authentication. IP address allowlisting only verifies network source location, failing to provide workload identity verification.

Takeaway 4: Centralized PII Masking at the Agent Gateway (sensitive_data_protection · api_gateway · vertex_ai:agents)

• Core Concept: Real-time egress inspection and sensitive data redaction before third-party LLM invocation
• Scenario Trigger & Requirement: The scenario requires an architectural pattern to safeguard sensitive patient data (PII/PHI) generated or processed within an agentic workflow. Key constraints include the requirement for a centralized approach and the absolute restriction that sensitive data must not cross the boundary to external third-party model endpoints.
• Winning Architecture & Implementation: Configure an agent API gateway with a pre-routing plugin that inspects and redacts sensitive data with Cloud Sensitive Data Protection before forwarding requests. Centralizing egress traffic inspection through an agent API gateway is the recommended architecture for enterprise governance.
• Exam Traps to Reject: Client-side filtering is decentralized, incomplete, and cannot intercept server-side agentic data enrichments. System prompts do not prevent sensitive data from crossing security perimeters and leaving the organization.

Consolidated Golden Rules (Consideration 5.1c):

• Use W3C Trace Context headers (traceparent) to propagate distributed trace identifiers across multi-agent hops.
• Agent Gateways act as central control points to inject trace headers and monitor incoming and outgoing traffic.
• Cloud Trace and OpenTelemetry correlate multi-step agent actions into a unified visual graph for latency analysis.
• Place an API gateway between AI agents and external tools to govern, monitor, and rate limit agentic traffic.
• Use token bucket rate limiting to prevent runaway infinite loops while accommodating normal bursts of tool calls.
• Key gateway policies by agent identity and endpoint to isolate misbehaving agents without affecting wider operations.

Consideration 5.1d: Designing and configuring agentic governance and policy enforcement (e.g., agent registry and model armor)

Combine catalog governance with runtime content inspection:

• Agent Registry (Catalog & Lifecycle Governance): Eliminates "Shadow AI" by requiring every production agent (Agent Card) and MCP server to be registered, security-vetted, versioned, and approved in Agent Registry. Unregistered endpoints are blocked at the Agent Gateway.
• Model Armor (Runtime Content & Injection Firewall): Inspects user prompts, retrieved RAG documents/tool outputs (stopping Indirect Prompt Injection!), and model responses to deterministically block jailbreaks, prompt injections, malicious URLs, and sensitive data leaks regardless of which foundation model the agent uses.

Takeaway 1: Preventing Indirect Prompt Injections via Model Armor (vertex_ai:model_armor · security:model_armor)

• Core Concept: Model Armor input sanitization and prompt injection defense
• Scenario Trigger & Requirement: A scenario where an AI agent ingests unstructured external text (emails) that may contain indirect prompt injections designed to hijack the model and exfiltrate internal system prompts. The goal is to sanitize inputs and intercept attacks prior to model execution.
• Winning Architecture & Implementation: Configure Model Armor with prompt injection and jailbreak filters in the ingress pipeline before the inputs reach the model. Model Armor provides automated input and output guardrails specifically designed for Large Language Models (LLMs). It intercepts inputs at the ingress layer and applies pre-configured filters for prompt injections, jailbreaks, and sensitive data to prevent malicious instructions from ever reaching the foundation model runtime.
• Exam Traps to Reject: Google Cloud Armor protects web applications from standard Layer 7 web attacks, not LLM prompt injections. Relying purely on system prompt instructions is vulnerable to advanced adversarial prompt injections.

Takeaway 2: Governing Multi-Environment Lifecycle via Centralized Agent Registry (vertex_ai:agent_builder · vertex_ai:governance)

• Core Concept: Agent Registry lifecycle tracking, versioning, and environment promotion
• Scenario Trigger & Requirement: An enterprise with distributed teams deploying agents independently across different Google Cloud environments (Dev, Staging, Prod). Because there is no centralized oversight, deprecated and untracked agent versions are reaching production and accessing sensitive corporate databases.
• Winning Architecture & Implementation: Establish a centralized agent registry with immutable versioning and lifecycle metadata, and enforce deployment gates that permit only approved versions in production. A centralized agent registry provides a single source of truth for agent configurations, tools, prompts, and code. Enforcing immutable semantic versioning and lifecycle metadata (such as development, staging, or production approval tags) ensures traceability.
• Exam Traps to Reject: Directly granting production access to dev environments violates least privilege and fails to govern agent lifecycles. Monitoring local prompt changes creates alerts but does not enforce promotion gates or prevent unauthorized production execution.

Takeaway 3: Automated PII Redaction in Agent Outputs via Model Armor and Sensitive Data Protection (vertex_ai:model_armor · security:sensitive_data_protection)

• Core Concept: Model Armor response inspection integrated with Cloud Data Loss Prevention
• Scenario Trigger & Requirement: The scenario requires sanitizing synthesized clinical summaries generated by an AI agent before care managers view the output. Key requirements are: (1) redacting Protected Health Information (PHI) in real time on the agent output/response path, and (2) minimizing custom development and maintenance overhead.
• Winning Architecture & Implementation: Configure a Model Armor template with Cloud Sensitive Data Protection inspection rules applied to model output responses to mask sensitive entities. Model Armor provides centralized guardrails for generative AI applications. By configuring Model Armor floor settings and response inspection policies integrated with Cloud Sensitive Data Protection (formerly Cloud DLP), you can automatically scan and sanitize LLM output payloads before care managers receive them.
• Exam Traps to Reject: Scheduled batch jobs only inspect data at rest and do not sanitize real-time agent responses. System prompts cannot deterministically guarantee PHI redaction due to model non-determinism and prompt injection risks.

Consolidated Golden Rules (Consideration 5.1d):

• Model Armor is the purpose-built Google Cloud security service for LLM input sanitization, prompt injection prevention, and output filtering.
• Do not rely solely on system prompt engineering or custom regex rules to block adversarial inputs.
• Cloud Armor protects standard HTTP web endpoints, whereas Model Armor protects Generative AI models from semantic and prompt-based attacks.
• A centralized Agent Registry provides visibility, metadata management, and version pinning across multi-project environments.
• Enforce immutable versioning to prevent unintentional drift or silent breakage when underlying prompts or tools change.
• Combine registry metadata with automated deployment gates to prevent deprecated or unapproved agent versions from accessing production systems.

Multi-Constraint Production Architecture Scenarios (Subsection 5.1)

Head-to-Head Architectural Trade-Off Clinic (Subsection 5.1)

Rapid Pattern-Trigger Cheat Sheet (Subsection 5.1)

Curated Official Google Cloud Documentation (Subsection 5.1)

• Vertex AI Agent Builder Overview — Describes architecture and authentication mechanisms for deploying enterprise agents and integrating external tools.
• Google Cloud Authentication Overview — Details how Google Cloud APIs rely on OAuth 2.0 access tokens and service account identities for secure machine-to-machine and user-delegated authorization.
• Vertex AI Agent Builder Overview — Overview of building, governing, and deploying enterprise-ready generative AI agents with Vertex AI.
• Generative AI Governance and Security — Best practices for implementing policy enforcement, security guardrails, and compliance tracking in AI architectures.
• Principal access boundaries overview — Describes how principal access boundary policies establish guardrails to restrict which resources specific principals can access across Google Cloud.
• Identity and Access Management (IAM) overview — Details core authorization mechanisms, service identities, and security controls for applications and agent workloads in Google Cloud.
• Agent Registery — Central catalog for registering, discovering, and governing agents, tools, and their metadata.
• Agentic Architecture and Governance on Google Cloud — Discusses design considerations, access controls, and policy cataloging for multi-agent enterprise deployments.
• Agent Gateway Overview — Explains how Agent Gateway secures and governs connectivity for all agentic interactions and tool calls.
• Principal access boundary policies overview — Explains how Principal Access Boundary (PAB) policies restrict the resources that specific principals can access across Google Cloud.
• Authentication and authorization for agents in Vertex AI — Details security, governance, and identity concepts for Vertex AI Agent Engine.
• API Gateway Overview — Explains how API gateways enforce authentication, rate limiting, and centralized monitoring across backend services.

Subsection 5.2: Designing safety guardrails and secure data access

Section 5: Securing and Governing Agentic Systems (15%) · 2 Official Considerations · 27 Scenarios Consolidated

Domain Overview and Reference Architecture

Preventing the "Confused Deputy" and Protecting Sensitive Data End-to-End

Even when an agent is authenticated and registered, two critical questions remain before it can safely operate in a regulated enterprise (healthcare, banking, retail, or public sector):

1. How do we prevent an autonomous agent from executing irreversible, high-impact actions or leaking PII/PHI (5.2a)?
2. How do we propagate the human user's identity all the way through multi-agent hops (Agent Gateway → Orchestrator → Sub-Agent → RAG / Database) so User A never sees User B's confidential records (5.2b)?

Section 5.2 of the PAA exam tests your ability to weave Defense-in-Depth Safety Frameworks (Model Armor, Sensitive Data Protection / Cloud DLP, Agent Gateway, and Human-in-the-Loop [HITL] checkpoints) together with End-to-End Identity Propagation and VPC Service Controls (VPC-SC).

Exam Scope Covered in This Chapter

• 5.2a Designing Appropriate Safety Frameworks and Guardrails (Agent Gateway, Model Armor, Human-in-the-Loop [HITL], Sensitive Data Protection): Implementing multi-layered input/context/output filtering, redacting or pseudonymizing PII/PHI with Sensitive Data Protection (DLP), and enforcing deterministic Human-in-the-Loop (HITL) approval gates for high-stakes or destructive tool calls.
• 5.2b Configuring Secure Access to Data and Identity Propagation (Agent Gateway, Agent Registry, VPC-SC): Propagating verified end-user identity claims across multi-agent and MCP hops so downstream databases and RAG indices enforce Row-Level Security (RLS) and Document-Level ACLs deterministically.

Core Foundational Primitives & Mental Models (Subsection 5.2)

Official Exam Considerations & Consolidated Takeaways (Subsection 5.2)

Consideration 5.2a: Designing appropriate safety frameworks and guardrails (e.g., agent gateway, model armor, and human-in-the-loop [hitl])

When designing safety architectures for high-stakes enterprise agents:

• Risk-Tiered Tool Execution & Human-in-the-Loop (HITL):
• Classify every tool by blast radius: Read-Only / Low-Risk tools execute autonomously; High-Impact / Financial / Destructive tools (e.g., issuing refunds over $500, modifying IAM policies, sending external customer emails, deleting records) must trigger a deterministic Human-in-the-Loop (HITL) interrupt before execution.
• Serverless HITL Architecture: Checkpoint the agent state to Firestore / Managed Sessions, emit an approval request event, terminate the compute invocation (so you never pay for idle CPU waiting hours for a human), and resume from the saved checkpoint upon receiving the signed approval callback.
• Defense-in-Depth with Model Armor + Sensitive Data Protection (DLP):
• Use Model Armor to block direct/indirect prompt injections, jailbreaks, malicious URLs, and toxic outputs across ingress, RAG context, and egress.
• Pair it with Sensitive Data Protection (Cloud DLP) to inspect and redact, mask, or deterministically tokenize (surrogate tokens) sensitive PII / PHI / PCI before prompts reach the LLM, before documents enter a RAG index, and before traces are written to Cloud Logging.

Takeaway 1: Model Armor Prompt Injection Sanitization (vertex_ai:model_armor · vertex_ai:security)

• Core Concept: Model Armor filter rules for jailbreak detection
• Scenario Trigger & Requirement: A security risk where untrusted user inputs contain prompt injection or jailbreak patterns targeting a generative AI agent. The goal is to inspect and neutralize these threats before they execute on the foundation model, while maintaining valid conversational context.
• Winning Architecture & Implementation: Configure Model Armor templates and filters on the prompt ingestion path to detect and sanitize prompt injection and jailbreak attempts. Model Armor is designed specifically for Large Language Model (LLM) security guardrails. It provides pre-execution sanitization and inspection for user prompts to detect prompt injection heuristics and jailbreak attempts before the payload reaches the foundation model.
• Exam Traps to Reject: Cloud Armor protects web infrastructure from network attacks rather than semantic LLM prompt injections. Static regex pattern matching easily fails against sophisticated or obfuscated prompt injection attempts.

Takeaway 2: HITL Thresholds for Financial Transactions (vertex_ai:reasoning_engine · workflows · cloud_run)

• Core Concept: Human-in-the-loop (HITL) governance for high-stakes tool execution
• Scenario Trigger & Requirement: The scenario requires establishing safety guardrails for an AI agent performing financial actions. Key constraints include: high-stakes monetary threshold (1,000 USD), uncertainty threshold (low model confidence), and the necessity to pause execution, persist state, and resume after human authorization (Human-in-the-Loop).
• Winning Architecture & Implementation: Configure an orchestration workflow with conditional branching that pauses execution by using callback hooks, and resumes processing after an operator approves the transaction. Implementing conditional branching with callback hooks in an orchestrator such as Cloud Workflows or Vertex AI Reasoning Engine provides a robust human-in-the-loop (HITL) architecture.
• Exam Traps to Reject: System prompts cannot deterministically halt or manage stateful human approval queues. Rejecting high-value transactions fails the requirement to support manual approval workflows.

Takeaway 3: Outbound PII and Toxic Output Redaction with Model Armor (vertex_ai:model_armor · security:sensitive_data_protection)

• Core Concept: Model Armor egress filtering and Cloud DLP integration
• Scenario Trigger & Requirement: The scenario requires an automated, robust guardrail to inspect and sanitize model outputs (egress) for PII/PHI in a regulated healthcare environment. The key technical considerations are applying outbound redaction policies deterministically before the end user receives the response.
• Winning Architecture & Implementation: Configure Model Armor to inspect egress responses and integrate Sensitive Data Protection templates to detect and redact sensitive infoTypes before delivery. Model Armor offers built-in guardrails designed to sanitize both user prompts (ingress) and model outputs (egress). By integrating Model Armor with Sensitive Data Protection (Cloud DLP), you can apply inspection templates that scan egress payloads for sensitive infoTypes (such as medical record numbers, names, and social security numbers) and automatically redact or mask them before the response reaches the user.
• Exam Traps to Reject: Restricting retrieval prevents the agent from reading required claims records rather than sanitizing generated responses. Prompt instructions are non-deterministic and cannot guarantee that the model will not output sensitive data.

Takeaway 4: Agent Gateway Policy Enforcement for Tool Calling (vertex_ai:agent_builder · cloud_run · apigee)

• Core Concept: Centralized policy enforcement and authorization via Agent Gateway
• Scenario Trigger & Requirement: The scenario requires establishing a centralized, uniform security mechanism to enforce OAuth validation and authorization for tool calls across diverse autonomous agents without rewriting individual agent logic.
• Winning Architecture & Implementation: Route all agent tool calls through a centralized Agent Gateway proxy that verifies authentication tokens and enforces authorization rules before calling backend services. An Agent Gateway operates as a secure intermediary layer between large language model (LLM) agents and internal microservice APIs.
• Exam Traps to Reject: Embedding administrative keys in containers violates least privilege and creates critical security risks. Prompt-based authorization is insecure and easily bypassed by prompt injection attacks.

Consolidated Golden Rules (Consideration 5.2a):

• Use Model Armor at the prompt ingestion layer to sanitize prompt injection and jailbreak attempts before foundation model execution.
• Standard web application firewalls (like Cloud Armor) and basic regex filters cannot reliably detect semantic, natural language adversarial attacks.
• Guardrails must operate bidirectionally: inspecting user inputs on ingress and filtering model completions on egress.
• Never rely solely on prompt engineering to enforce strict security boundaries or financial thresholds.
• Use workflow orchestrators with built-in callback hooks to achieve scalable, cost-effective, and stateful human-in-the-loop (HITL) approval gates.
• Gate high-stakes tool execution on both deterministic business thresholds and probabilistic model confidence scores.

Consideration 5.2b: Configuring secure access to data and identity propagation (e.g., agent gateway and agent registry)

Preventing cross-user and cross-tenant data leakage ("Confused Deputy" at the data layer) requires strict identity propagation:

• Propagate Verified User Identity Through Agent Gateway: When User A queries an orchestrator agent, which delegates to Sub-Agent B (discovered in Agent Registry), which queries a database MCP server, do not drop User A's identity and fall back to a shared service account! Propagate the verified user identity token (or exchange it via OAuth 2.0 On-Behalf-Of [OBO] at Agent Gateway) across every hop.
• Deterministic Data-Layer Filtering Beats Prompt Filtering:
• Never pass all tenants' data to the LLM and ask the prompt to "only show records belonging to the current user."
• Enforce access deterministically at the storage/retrieval layer using the propagated user identity:
• Unstructured Enterprise Docs: Use Agent Search (Vertex AI Search) with native Document-Level ACL inheritance, or inject verified JWT claims directly into Vector Search metadata pre-filters inside backend code.
• Structured Databases (BigQuery, Cloud SQL): Enforce Row-Level Security (RLS) or Authorized Views bound to the authenticated user principal.
• Exfiltration Perimeter: Wrap sensitive Google Cloud data stores and Vertex AI endpoints inside a VPC Service Controls (VPC-SC) perimeter.

Takeaway 1: End-User Identity Propagation via OAuth 2.0 Token Exchange (vertex_ai:agents · cloud_run:security · iam:service_accounts)

• Core Concept: Propagating end-user identity through an agent framework to down-stream services using RFC 8693 token exchange rather than a shared service account.
• Scenario Trigger & Requirement: Two critical architectural constraints: executing downstream microservice operations under the individual caller's identity (to enforce row-level security and detailed audit logs) and avoiding shared service accounts. This requires a mechanism that safely carries the caller's authenticated identity through the agent infrastructure.
• Winning Architecture & Implementation: Configure the Agent Gateway to perform OAuth 2.0 token exchange to trade incoming user tokens for downstream access tokens. Configuring the Agent Gateway to perform OAuth 2.0 token exchange (RFC 8693) allows the agent framework to trade the caller's initial identity token for a scoped, downstream access token that preserves the caller identity.
• Exam Traps to Reject: Shared service accounts mask the real caller identity and violate row-level security and auditability mandates. Agents should never store or handle raw end-user passwords.

Takeaway 2: Cryptographic Verification and Discovery via Agent Registry (security:binary_authorization · security:iam · vertex_ai:agent_builder)

• Core Concept: Enforcing agent provenance and runtime tool validation using a centralized Agent Registry with cryptographically signed metadata.
• Scenario Trigger & Requirement: A multi-agent environment where agents dynamically discover and invoke sub-agents. The key risk is rogue agents spoofing diagnostic tools or registering unverified capabilities.
• Winning Architecture & Implementation: Publish agent metadata to a centralized Agent Registry with cryptographically signed manifests, enforce Binary Authorization on deployments, and restrict discovery endpoints with Cloud IAM. A centralized Agent Registry serves as the authoritative catalog for available agents and tools. By requiring cryptographically signed manifests and pairing them with Binary Authorization for containerized workloads, you ensure that only verified, tamper-proof agent artifacts run in your environment.
• Exam Traps to Reject: Static API keys are insecure and do not provide provenance verification or centralized registry discovery. Network filtering and IP allowlists do not verify the cryptographic integrity or provenance of agent manifests.

Takeaway 3: Workload Identity Federation for Secure Multi-Cloud Tool Access (vertex_ai:agent_builder · iam:workload_identity_federation)

• Core Concept: Eliminating static service account keys when an agent running in Google Cloud needs to access external cloud data stores.
• Scenario Trigger & Requirement: The scenario requires an AI agent on Vertex AI to access third-party data platforms (Amazon S3 and Snowflake) while strictly prohibiting the creation, storage, or management of static credentials and API keys. The solution must provide secure, temporary, short-lived authentication for external tool execution.
• Winning Architecture & Implementation: Configure Google Cloud Workload Identity Federation and OpenID Connect (OIDC) token minting to exchange short-lived Google identity tokens for temporary access roles on external platforms. Workload Identity Federation and OpenID Connect (OIDC) token minting allow workloads running in Google Cloud to exchange short-lived Google Cloud identity tokens for temporary credentials in external systems like AWS and Snowflake.
• Exam Traps to Reject: Service account keys are static secrets, and placing them in prompts creates security vulnerabilities. Storing static API keys in Secret Manager violates the requirement to eliminate static secrets.

Takeaway 4: Agent Gateway Mediation for In-line DLP and Data Sanitization (vertex_ai:agents · sensitive_data_protection:dlp · cloud_run:proxy)

• Core Concept: Positioning an Agent Gateway as a reverse proxy for all agent-to-tool egress calls to inspect and redact sensitive data.
• Scenario Trigger & Requirement: Requires a secure, centralized method to ensure that PII and API keys in diagnostic logs never leave the Google Cloud perimeter when an agent invokes an external third-party tool. Crucially, the solution must work in real time and avoid modifying prompt or agent logic.
• Winning Architecture & Implementation: Route outbound tool requests through an Agent Gateway reverse proxy that integrates with Sensitive Data Protection to inspect and de-identify payloads before egress. Deploying an Agent Gateway as a reverse proxy decouples data security and governance from the core agent application logic.
• Exam Traps to Reject: Prompt-based masking is nondeterministic and insufficient for strict data security compliance. Batch scanning source storage deletes needed diagnostic data and does not protect dynamic, real-time tool calls.

Consolidated Golden Rules (Consideration 5.2b):

• Always avoid shared ambient service accounts when downstream systems require caller auditability or row-level access control.
• Use OAuth 2.0 Token Exchange (RFC 8693) at the Agent Gateway to trade caller tokens for downstream scoped tokens.
• Identity propagation ensures the authenticated end-user context travels cleanly across multi-tier agent workflows.
• Use a centralized Agent Registry with cryptographically signed manifests to guarantee agent provenance.
• Implement Binary Authorization to enforce deployment integrity on containerized agents.
• Gate agent discovery and invocation endpoints with fine-grained Cloud IAM policies.

Multi-Constraint Production Architecture Scenarios (Subsection 5.2)

Head-to-Head Architectural Trade-Off Clinic (Subsection 5.2)

Rapid Pattern-Trigger Cheat Sheet (Subsection 5.2)

Curated Official Google Cloud Documentation (Subsection 5.2)

• Google Cloud Model Armor Overview — Documentation describing how Model Armor helps protect generative AI applications and agentic workflows from prompt injection attacks, jailbreaks, and malicious inputs.
• Build AI Agents with Vertex AI Agent Builder — Provides an overview of building, evaluating, and governing generative AI agents on Google Cloud.
• Responsible AI practices in Google Cloud — Explains recommended safety and governance practices, including human-in-the-loop controls for AI systems.
• Sensitive Data Protection Overview — Provides a comprehensive overview of how Sensitive Data Protection discovers, classifies, and de-identifies sensitive data in text and storage.
• De-identifying sensitive data in text — Explains transformation methods such as masking, tokenization, and redaction on unstructured text payloads.
• Vertex AI Agent Builder - Extensions authentication and security — Describes authentication methods for extensions and tools in Vertex AI Agent Builder, including end-user OAuth token pass-through and service identity delegation.
• Authentication in Vertex AI Search and Conversation — Details access control and user identity propagation patterns when connecting external data stores to generative AI search engines and agent workflows.
• Securing Generative AI on Google Cloud — Explains responsible AI practices, content filtering, and safety guardrails across generative AI applications on Vertex AI.
• Model Armor overview — Provides architectural details on configuring Model Armor guardrails to protect LLM applications against prompt attacks, system prompt leakage, and harmful content.
• Vertex AI safety filters and guardrails — Details safety configurations and threat mitigation strategies for foundation models on Google Cloud.
• Cloud Workflows - Waiting for callbacks — Describes how to create callback endpoints to pause workflow execution until an external event or human approval occurs.
• Vertex AI - Overview of AI agents and safety — Covers design patterns for governing agentic workflows and integrating guardrails into reasoning engines.

Book TOC · Previous · Chapter 7 of 8 · Next