Training Agent Governance with Design Problems — AI Drafts Scored Against Official Best Practices

The exam guide for Google Cloud’s Professional Agentic Architect allocates about 15% of the exam to §5, “Securing and governing agentic workflows”, and about 13% to §1, “Building agents using low-code tools” (as of October 2026). Questions on agent governance are hard to answer by memorizing product names. You need to assemble a single design: which identity the agent runs under, where traffic is stopped and where a person approves. On top of that, most of the products behind §5 only reached general availability (GA) between April and August 2026, and without a Google Cloud account you cannot learn them by running them locally.

This article contains affiliate links. As an Amazon Associate, we earn from qualifying purchases.

So here we ran one round of an exercise with an AI: write a design and score it. We had Claude Code’s claude -p solve a design problem we wrote (not an exam question) once each under two conditions: condition A with the problem only, and condition B with the §5 items of the exam guide added as viewpoints. We scored the designs with a 15-row rubric built from Google Cloud and ADK documentation. In this run A met 7 of 15 rows and B met 10 of 15. Among the rows both missed, Auth Manager went GA after the model’s knowledge cutoff (June 2026). But the deny rule, which both also missed, has been GA as IAM deny policies since 2022, so the cutoff does not explain it.

The 15 rubric rows are published below with the pages they come from, so you can score your own design or an AI’s with the same table. We have not taken this exam, nor checked anything with a Google Cloud account; product settings and behavior follow the official documentation as of October 2026.

What §5 and §1 of the exam guide ask

§5 is titled “Securing and governing agentic workflows” and has two subsections. 5.1, configuring agent security and governance, lists four considerations:

• Authentication and secure tool execution (example: agent-to-tool API calls using OAuth 2.0)
• Configuring principal access boundary (PAB) policies with Agent Identity
• Configuring Agent Gateway to monitor traffic and track agents
• Designing and configuring agent governance and policy enforcement (examples: Agent Registry and Model Armor)

5.2, implementing secure agent behavior and execution, lists two:

• Designing appropriate safety frameworks and guardrails (examples: Agent Gateway, Model Armor, human-in-the-loop [HITL])
• Configuring secure data access and identity propagation (examples: Agent Gateway and Agent Registry)

Permissions are not confined to §5. §3.2 has “Configuring agent permissions (e.g., Agent Identity)”, and §3.3 names Agent Identity, Agent Registry, Agent Runtime and agent policies. The in-scope tool list also includes “Auth Manager (OAuth 2.0)” and “Sensitive Data Protection”, which the §5 text does not mention. The exam overview and the path from registration to certification are in What the Google Cloud Professional Agentic Architect Certifies.

All §5 components are configured on Google Cloud. The local practice of writing and running ADK agents on your own PC (Run ADK Agents Locally with Ollama) does not work here. So we replace it with writing designs in prose and scoring them against official best practices. §1’s low-code products are summarized from official docs in the second half.

Identity, permissions and authentication — official points on Agent Identity, PAB and Auth Manager

Agent Identity — one identity per agent

Agent Identity gives each agent a cryptographic identity; the docs call it “a strongly attested, cryptographic identity for each agent”, based on the SPIFFE standard. Compared with service accounts, it is not shared across workloads by default, cannot be impersonated, and cannot have long-lived service account keys. The official pitch is to replace shared service accounts with per-agent identities and eliminate over-privileged agents.

The overview lists three supported services: Agent Runtime (formerly Agent Engine), Gemini Enterprise and Cloud Run. The page for configuring it on Cloud Run is marked Preview, and GKE, absent from that list, has a preview “Agent Identity for GKE” doc (both as of October 2026). Identity certificates (X.509) are valid for 24 hours. Two operational points feed the rubric: when an agent acts on behalf of a user, logs record both the agent’s and the user’s identity; and deleting an agent does not remove IAM bindings that reference its identity — you must remove them by hand as part of decommissioning.

PAB — the upper bound on what an agent can reach

Principal Access Boundary (PAB) policies cap the resources an agent can reach. Per the docs, whatever other permissions the agent has, PAB limits the resources it can access. The resources you can write as the bound (the rule’s resources) are organizations, folders and projects, and the bound covers those and their descendants; the REST spec lists the same three types and no in-project resources such as BigQuery datasets. Project-level principal sets include agent identities alongside service accounts and workload identity pools.

But PAB only blocks access that uses permissions PAB supports (the docs say it will “only block access attempts that involve supported permissions”), so you cannot read it as “PAB stops every permission”. Setting the enforcement version to latest is discouraged because it can cut off access unexpectedly. Limits: 500 rules per policy, 1,000 policies per organization and 10 policies bound to one principal set.

General IAM best practices

Beyond agent products, we put IAM’s general best practices (the official page “Use IAM securely”) into the rubric: do not grant basic roles in production; use the narrowest predefined or custom role that meets the need; grant roles at the smallest necessary scope and separate trust boundaries per application component; and avoid service account keys when there is another way. The ADK safety guide says the same: if a resource gets only read-only permission, the tool cannot write no matter what the model decides.

Auth Manager — hand off external API authentication

“Auth Manager (OAuth 2.0)” in the tool list is called “Agent Identity auth manager” in the docs. It is a service that centralizes a credential vault and authentication brokering for external tools. API keys, OAuth client secrets and user tokens go into a Google-managed vault, avoiding hard-coding or storing them in your own database. It also handles OAuth 2.0’s multi-step flows — user consent, authorization-code exchange and token refresh — without your own backend code.

The authentication recommendations are on the Agent Identity overview: 2-legged OAuth for machine-to-machine authentication with OAuth-capable external services, 3-legged OAuth when the agent acts for a specific user, and not HTTP basic authentication with plain-text passwords. When Agent Identity is combined with both Agent Gateway and Gemini Enterprise, Auth Manager encrypts user credentials prepared by Gemini Enterprise connectors and the gateway decrypts them, so the agent never touches raw credentials. In the flow of using Auth Manager from ADK on Agent Runtime, by contrast, Auth Manager returns the credential (an API key or OAuth token) to the agent, which attaches it to calls to the external API. There are also limits, such as GitHub and Microsoft integrations being restricted to a single scope.

Traffic and inspection — official points on Agent Gateway, Agent Registry and Model Armor

Agent Gateway — an entry and exit point that denies by default

The docs call Agent Gateway Agent Platform’s “key enforcement component”: the network entry and exit point for all agent interactions. By default it blocks every connection and lets through only what IAM policies explicitly allow. It has two modes, inbound from clients to agents (Client-to-Agent) and outbound from agents to anywhere (Agent-to-Anywhere). Network-layer traffic records go to Agent Observability, and the gateway’s allow and deny decisions are logged.

Mind which runtimes it governs. The overview lists two: Agent Runtime, with both inbound and outbound, and Gemini Enterprise, with outbound only — no inbound mode. Cloud Run and GKE are not in that list. The preview “Agent Identity for GKE” doc, however, says GKE agents can be combined with Agent Registry and Agent Gateway, and that Agent Gateway is used to apply IAM policies to traffic between agents registered in Agent Registry. Since the docs differ in scope and the GKE doc is a preview, treat a design that uses Agent Gateway on GKE as relying on a preview feature, and keep it separate in your mind from Agent Identity’s Cloud Run support. Per the overview’s limitations, one Agent Gateway can govern up to 5,000 resources registered in Agent Registry.

Agent Registry and IAM policies

Agent Registry is a central catalog for storing, discovering and governing agent components. The Agent Gateway overview recommends registering call targets in Agent Registry and writing fine-grained access policies per resource and per tool. Unregistered destinations need an explicit IAM access policy targeting that URL (with the recommended IAM Unified Access Policies, the rule condition names the destination host and path). Agents on Agent Runtime and Gemini Enterprise automatically get an Agent Identity and an Agent Registry entry.

The IAM policies Agent Gateway uses have allow and deny rules. The “Best practices” section of the IAM Unified Access Policies (UAP) overview lists four:

• Deploy new or changed policies in dry-run mode first to verify them without stopping live traffic (dry-run records disallowed traffic in Cloud Audit Logs without blocking it)
• Grant only needed permissions and write specific tool names or paths, not wildcards, in CEL conditions
• Implement critical guardrails, such as destructive tool calls against production targets, with explicit deny rules
• Review Cloud Audit Logs and policy configuration regularly

The same page says deny rules take precedence over allow rules, which makes them suited to guardrails; its example is a deny rule that forbids an agent to delete or update database records.

Model Armor and Sensitive Data Protection

Model Armor is a Google Cloud service that improves the security of AI applications by inspecting both inputs (prompts) and outputs (responses). Its overview recommends separate templates for user prompts and model responses (“Considerations and best practices”), starting in Inspect only mode to learn the block rate and effectiveness (“Define the enforcement type”), and setting organizational minimums with floor settings (“Model Armor floor settings”). Inspect only is useless without Cloud Logging enabled, and you cannot create templates weaker than the floor settings.

Combined with Agent Gateway, it inspects inbound client prompts for injection and harmful content, and outbound content sent to tools and agent responses for data leakage and injection. This integration cannot inspect prompts or responses that include documents or file uploads such as PDFs; to inspect files, call the Model Armor API directly (Model Armor scans files up to 4 MB). Model Armor and the integrated service must be in the same region, inbound inline protection covers only agents built with ADK, and outbound inline protection is limited to MCP servers, OpenAI-style services and A2A through Agent Gateway.

Model Armor is not the only way to inspect for prompt attacks. CX Agent Studio’s guardrails include a prompt guard, and preview Semantic governance policies also inspect tool calls; for the latter, the docs say judgments may be inaccurate because natural-language policies are evaluated by an LLM.

Sensitive Data Protection (SDP) inspects and masks sensitive information such as personal data and credentials. Used inside Model Armor, the basic configuration only inspects, cannot use SDP templates, and detects mainly US-oriented info types. The advanced configuration can both inspect and de-identify, with info types chosen through templates. For designs handling non-US personal data — Japanese, in our problem — this difference affects the score.

Release status (October 2026)

Dates are the announcement dates in each product’s release notes. Names and status change month by month, so reopen the official release notes whenever you design.

Prompt injection and data leakage, which Model Armor inspects for, are risks shared by every generative AI application. Apart from product settings, a book that treats guardrails and evaluation as part of building foundation-model applications helps frame those risks.

AI Engineering: Building Applications with Foundation Models

USD 52.40 on Amazon.com (as of 2026/09/22)

Amazon

ポチップ

An agent governance rubric — 15 rows built from official best practices

From the documents above, we split what a design should contain into 15 rows. Each row is judged 0 or 1: 1 if there is a concrete statement that meets “counts as met”, 0 otherwise. Merely naming a product — for example, “use Model Armor” with no distinction between input and output — scores 0. Rows that are hard to call are put on hold, with the reason recorded, and left out of the total. The total is written as “number of 1s / number of judged rows”.

The exam guide column gives the subsection each row corresponds to. Row 11’s SDP is not named in the §5 text but is in the in-scope tool list. Row 12’s human approval is a design pattern, not a product, so it is judged by “the approval stage and where it happens”, whatever the means.

Statements counted as errors

Separately from gaps, the following statements are counted as errors, recorded even when the row scores 1:

• E1: Saying Agent Gateway governs traffic of agents on runtimes its overview does not list, such as Cloud Run (the overview lists Agent Runtime and Gemini Enterprise). GKE is not counted as E1 because the preview Agent Identity for GKE doc mentions Agent Gateway integration; if a design touches it, we record whether it says “preview”
• E2: Saying Model Armor via Agent Gateway also inspects files such as PDFs
• E3: Placing inbound (Client-to-Agent) Agent Gateway in front of agents on Gemini Enterprise
• E4: Implementing approval by combining ADK Tool Confirmation with Agent Runtime’s managed sessions (VertexAiSessionService)
• E5: Using product or parameter names that do not exist
• E6: Saying PAB stops every permission

What was left out of the rubric

Some candidates did not make it into the rubric. Semantic governance policies are in preview, the docs warn their judgments may be inaccurate, and the exam guide does not name them. VPC Service Controls (perimeters that prevent data exfiltration) were left out because we could not pin down which part they affect when combined with Agent Gateway. The ADK safety guide’s “Design tools defensively” is not among §5’s examples and overlaps rows 2 and 7. The Cloud Trace integration, skill management in Agent Registry and Model Armor’s image inspection are all in preview and were left out.

The design problem and run conditions

The problem is our own, not an exam question; no official sample or practice-question text is used. So that all 15 rows can be judged, we fixed the runtime to Agent Runtime and included a read-only database, an external API that supports OAuth 2.0, hard-to-undo orders, ordering in an employee’s name, personal data and a planned rebuild. If the AI chose the runtime and picked Cloud Run, the Agent Gateway rows could not be judged. The full text given in condition A, translated from Japanese:

A small company that does 3D printing on commission wants to put an AI agent on Google Cloud that checks stock and orders filament from suppliers. Conditions:

- The runtime is Agent Runtime (formerly Agent Engine). The agent is built with ADK.
- Stock data is in a BigQuery table, and the agent only needs to read it. The table also contains the names and phone numbers of supplier contacts (Japanese personal data).
- Orders are placed through an external supplier’s API, which supports OAuth 2.0. Orders have amounts and are hard to cancel once sent.
- Employees call the agent, and orders are placed in the name of the employee who requested them.
- This agent is planned to be rebuilt and replaced by a new agent next year.

Write a design for operating this agent safely on Google Cloud, covering permissions, authentication, network traffic, input/output inspection, human approval, and logging and auditing, naming concrete products and settings, in Japanese (up to about 2,000 characters).

In condition B we appended “In the design, address all of the following viewpoints (the items of §5 of the Google Cloud Professional Agentic Architect exam guide, verbatim).” followed by the six items of 5.1 and 5.2 in the original English. That passage is the only difference between the conditions.

We used claude -p with –model sonnet and a minimal setup that loads no tools, MCP servers or settings, once per condition (2026-10-12). The system prompt in both conditions was the single sentence “You are a careful assistant.”, and the recorded model ID was claude-sonnet-5-5 (Claude Sonnet 5.5). Cost was $0.063 for A and $0.053 for B; counting spaces, line breaks and Markdown symbols, the designs were 2,861 and 2,494 Japanese characters long. We judged each row against the rubric and recorded the passage behind each judgment. Judging was done once, with no cross-check between multiple judges.

Results — 7 of 15 with the problem only, 10 of 15 with the §5 items

Neither design contained the predefined errors E1–E6 (E4 was put on hold for both and E6 for B, for reasons given later). That is only within E1–E6; B’s description of PAB has an inaccuracy outside those six, covered in a later section.

Seven rows were met by both: agent identity (#1), least privilege (#2), input and output inspection (#9), personal data inspection (#11), human approval (#12), employee identity propagation (#13) and decommission cleanup (#15). For #1, B named Agent Identity, while A met it with an agent-only service account and a ban on creating keys. For #2, both exposed an authorized view of the stock table without the personal-data columns, granted only data-read and job-run roles, and granted no write permission. For #15, both wrote numbered decommissioning steps in response to the planned rebuild.

Five rows were missed by both: Auth Manager (#4), deny rules (#7), record-only mode (#8), floor settings (#10) and regular audits (#14). For #14, both wrote Cloud Audit Logs, storage in a retention-locked bucket and alerts, but no routine for reviewing the records periodically; since the rubric requires both recording and review, both scored 0 on the same basis. #11 is 1 for both, but neither said whether it used an advanced-configuration template, which Japanese personal data needs. B alone met three rows — PAB (#3), Agent Gateway (#5) and Agent Registry (#6) — all of them rows whose products appear as examples in the §5 text.

The problem-only design was built from established components

Condition A’s design never used Agent Identity, PAB, Agent Gateway or Agent Registry. Instead it was built from components long used on Google Cloud. For identity, it said to “specify a dedicated service account sa-orderagent-v1@… for Agent Runtime” and blocked key creation with the organization policy iam.disableServiceAccountKeyCreation. Traffic was enclosed in a VPC Service Controls perimeter, with outbound traffic sent “to our own VPC via a Private Service Connect interface (to be confirmed)” and only the supplier API’s domain allowed through Secure Web Proxy.

External API authentication (#4) followed the same pattern. A used the authorization-code flow with per-employee consent for the supplier’s OAuth 2.0 and kept refresh tokens out of the agent session, which answers the employee-name condition (#13 is 1). But token handling was done by building “a small Cloud Run service for token brokering” itself, with no mention of Auth Manager — the design builds by hand the token management that Auth Manager says it handles without your own backend code.

This does not mean A’s design is unsafe. We did not check how A’s components fit together on Agent Runtime, and A itself marks Private Service Connect “to be confirmed”. What the rubric measures is alignment with the components §5 names as examples and with official best practices. Since the guide names those components in §5, the gap is worth noticing when preparing for the exam.

Giving the §5 items as viewpoints added the product-named rows

Condition B’s design began by noting that the setting names were at the policy level and should be checked against the latest official docs before implementation, then used the §5 example products in turn. For identity it said to give the agent a dedicated Agent Identity and not use default or shared accounts. It created “an organization-level Principal Access Boundary policy” limited to “this project and the stock dataset”. Outbound traffic went through Agent Gateway with an allowlist of destinations, and the agent and its two tools (BigQuery read and the ordering API) were registered in Agent Registry. That turned #3, #5 and #6 to 1, and #1 also became 1 with Agent Identity named.

But #3 = 1 means the rubric condition (name PAB and what it limits) was met, not that B’s PAB configuration can be built as written. PAB rules can name organizations, folders and projects, covering those and their descendants; BigQuery datasets are not a supported type, so “limited to the stock dataset” cannot be configured with PAB. In B’s design PAB can bound access only down to the project; narrowing to the dataset is the job of the IAM role B wrote under the same heading (BigQuery Data Viewer on the stock dataset). This matches none of E1–E6, so it is not counted as an error, but we recorded it as an inaccuracy outside the rubric.

Meanwhile Auth Manager (#4) stayed at 0 in B. B chose the 3-legged authorization-code flow, obtained tokens with “ADK tool authentication (AuthConfig, request_credential)” and said “tokens are kept in managed storage”, but named no storage product. The §5 text says only “OAuth 2.0”; the name Auth Manager appears only in the tool list. In this run, components named in the viewpoint text made it into the design, and mechanisms not named there (Auth Manager, deny rules, dry-run, floor settings) did not.

B’s PAB paragraph also asserted that even if IAM grants were wrong, resources outside the boundary could not be accessed. The Agent Identity overview says PAB limits reachable resources regardless of other permissions, which is close to that; the PAB page says PAB only blocks access involving supported permissions. Because the official docs are worded differently, we put this on hold rather than counting it as E6. In design, though, it is safer to assume access through unsupported permissions is not stopped by PAB and to combine PAB with other mechanisms (least privilege and deny rules).

Auth Manager, missed by both, went GA after the knowledge cutoff

Anthropic’s model overview gives Claude Sonnet 5.5 a reliable knowledge cutoff and training data cutoff of June 2026, month only. Setting the rows both designs missed against that cutoff:

Agent Gateway and Agent Registry, which B could use, went GA on June 18, 2026, the same month as the cutoff. A did not use them, and B used them once their names were given in the §5 text. The exam guide PDF’s metadata shows a creation date of August 31, 2026, also after the cutoff: the scope is written in terms of products newer than the model’s knowledge.

Still, this one run cannot establish that the cutoff caused the gaps. Auth Manager was announced in preview in April 2026, before the cutoff. The deny-rule gap cannot be explained by the cutoff: IAM deny policies went GA in October 2022, and the Agent Identity overview says it supports both IAM allow and deny policies; what went GA after the cutoff is UAP, which puts allow and deny rules in one policy. Floor settings and regular reviews may have been missed regardless of the cutoff. What we can say is only that, in this run, features that went GA after the cutoff were missing from both designs.

So if you learn by having an AI draft designs, we recommend giving it the rubric’s source pages first. This run did not test a condition with official docs attached. How AI answers change before and after receiving materials is compared for the 28 in-scope tools in Agentic Architect Exam Scope: What AI Knows About 28 Tools.

Write human approval (HITL) as a design pattern — a caution on Tool Confirmation

Both designs met the human-approval row (#12). Each made the ordering tool unable to run without approval, showed the supplier, item, quantity, amount and requester (the name on the order) on the approval screen, and required a manager’s approval above a certain amount. Both also said to stop if a hash of the approved content does not match what is executed, and to attach an idempotency key to prevent duplicate orders. Those two points are outside the rubric but read as safeguards against drift between approval and execution.

Google Cloud’s design guide (the Cloud Architecture Center page “Choose a design pattern for your agentic AI system”) recommends the human-in-the-loop pattern for work needing human oversight, subjective judgment or final approval of critical actions, giving approval of high-value transactions as an example. It also notes the pattern can add significant design complexity because you must build and maintain external systems for user interaction. That is why the rubric asks not just for the approval stage but for who approves where. The Architecture Center’s security operations (SOC) use case also has an item “Implement human-in-the-loop approval.”

The means of implementation need care. Both designs proposed using ADK’s Tool Confirmation (require_confirmation) on Agent Runtime (A as one of two options alongside long-running tools). The ADK docs say setting it to True asks for confirmation before the tool runs, but also state that Tool Confirmation is experimental with known limitations and does not support VertexAiSessionService — which is what Agent Runtime’s managed sessions use. Neither design specified the session type, so E4 was put on hold for both; A did list “the latest spec of ADK’s tool confirmation” among items to verify before rollout.

Human approval is a design pattern, not a feature of one product, and there are other means than ADK’s Tool Confirmation. On the low-code side, when a Workflow Builder run reaches an approval step it stops and appears in the Runs tab with status “Needs Review”. When human approval comes up in exam preparation, think through which means, where the approval lives and whether that means has constraints.

Who approves what, and where, is less a product setting than an agent design question. A practical book on building agents end to end, including where people stay in the loop, is a useful companion here.

AI Agents in Action, Second Edition

USD 47.48 on Amazon.com (as of 2026/09/22)

Amazon

ポチップ

§1 low-code — Agent Designer (Workflow Builder), CX Agent Studio and Agent Search

§1 (about 13%) has two subsections. 1.1 is configuring agentic workflows and behavior with low-code tools: configuring state-based workflows (pages, transition routes, event handlers) and writing system instructions and in-console prompt templates (few-shot and chain-of-thought), with Gemini Enterprise’s Agent Designer and CX Agent Studio as example tools. 1.2 is connecting enterprise data to Gemini Enterprise: configuring secure connections to and queries over internal data (examples: Gemini Enterprise and Agent Search), and ingesting unstructured multimodal data such as video, audio and images; we did not research the latter.

Agent Designer has been announced under the name Workflow Builder (formerly Agent Designer) since September 2026; the exam guide PDF predates that and uses the old name. The docs describe Workflow Builder as a no-code/low-code interactive platform in the Gemini Enterprise web app for creating, managing and enabling chat agents and workflows, built with natural-language prompts or a visual editor. The actions and tools that agents and workflows can use are limited to the data connectors, tools and permissions a Gemini Enterprise administrator has provided — governance is built into the low-code tools too.

The guide’s “pages, transition routes, event handlers” are Dialogflow CX terms. Dialogflow CX models a conversation as a state machine, with pages representing session state; handlers control the conversation by producing responses or moving from the current page to another. CX Agent Studio is, in the docs’ words, a “minimal code” conversational agent builder built on ADK and an evolution of Dialogflow CX (GA announced February 4, 2026). It can build agents that use flows, and the conversation is handed to the flow until it reaches END_SESSION. So these three concepts belong to Dialogflow CX flows; do not learn them as Workflow Builder features.

For “secure connections” in 1.2, Gemini Enterprise’s permission-aware enterprise search is the official clue; the edition comparison marks it for every edition. Agent Search (formerly Vertex AI Search) is a service for building Google-quality search experiences and is presented as GA on its product page.

Gemini Enterprise requires a per-user license, which requires an edition subscription (monthly or annual). The editions are Business, Standard, Plus, Pay-as-you-go and Frontline, and Plus has a 30-day free trial. We do not state prices: Pay-as-you-go is billed monthly by usage with an official price table, but we could not find the other editions’ prices in the official docs. Everything about §1 here is a summary of official docs; we have not used these products.

What this run cannot tell us

• One run per condition; we did not measure how rows change if the same problem is solved again. The gap between 7/15 and 10/15 is the gap between single runs
• Only Claude Sonnet 5.5 was compared; generalizations like “AI does not use Agent Gateway” are not possible
• Scoring was done by the AI we use for this site (Claude), and a separate run of the same company’s AI reviewed every cell afterwards. No humans or other vendors’ models checked it, so the scorer is from the same company as the model that wrote the designs. Someone who requires Agent Identity to be named would score A’s #1 as 0 (A would then be 6/15), and the held E4s and B’s E6 could go either way
• The rubric is ours, built from official best practices, not the exam’s scoring; scores do not indicate pass or fail
• Attaching official docs to the AI was not tested
• The designs were not built and run on Google Cloud; we did not check that A’s Private Service Connect and Secure Web Proxy or B’s identity propagation work as written
• Product names and status are as of October 2026 and change month by month

Scoring your own design with the rubric

You can use this rubric to score your own designs:

1. Read the problem above and write your own design before looking at the AI’s. Headings for the six viewpoints — permissions, authentication, traffic, input/output inspection, human approval, logging and auditing — make it easier
2. Judge the 15 rows from the top as 0, 1 or on hold, and count errors (E1–E6) separately. Rows that only name a product score 0
3. For each 0, open the source page, read the original text and write one sentence on what to add where to make it 1
4. Have an AI solve the same problem, score it with the same table and compare it with yours. Asking with the problem only and with the §5 items shows how the framing of viewpoints changes the design
5. Change the problem’s conditions to test other rows and errors: with Gemini Enterprise as the runtime, the outbound-only limit (E3) comes into play; adding a PDF quote to orders brings in file inspection (E2)

The question of what to let an agent do without approval comes up in the same form with local coding agents. Claude Code’s permission model is covered in Decide Claude Code Permissions and Cost Before You Leave It Running, and the coding-agent settings in the exam guide in Claude Code Settings Tried Locally.

Summary — write agent governance down to “where it stops and who approves”

The agent governance that §5 tests cannot be met by listing product names. Give each agent its own identity with Agent Identity, cap reachable resources with PAB, deny by default at Agent Gateway, stop critical operations with deny rules, inspect inputs and outputs with Model Armor and have a person approve hard-to-undo operations. Then write down what you try first in record-only mode and who reviews the records regularly, and all 15 rubric rows are covered.

In our single runs, the design given only the problem was built from established components and met 7 of 15 rows; the design given the §5 items met 10 of 15. Adding the items increased the product-named rows, but neither design mentioned Auth Manager or deny rules, and the second asserted more about PAB than the docs support. Of the two gaps, Auth Manager went GA after the model’s knowledge cutoff; deny rules cannot be explained by the cutoff, since IAM deny policies have been GA since 2022.

Having an AI draft designs pays off only with a rubric and the official pages. Score your design and the AI’s with the same 15 rows and read the original text for each row that scores 0. Repeating that is preparation for being asked §5 design questions.

Sources

• Professional Agentic Architect exam guide (PDF)
• Agent Identity overview
• Principal access boundary policies
• IAM API v3: principalAccessBoundaryPolicies
• About Agent Identity for GKE
• Configure Agent Platform features for Cloud Run
• Agent Identity auth manager overview
• Use IAM securely
• IAM release notes
• Agent Gateway overview
• Monitor traffic through Agent Gateway
• IAM Access policies overview (Unified Access Policies)
• Semantic governance policies overview
• Gemini Enterprise Agent Platform release notes
• Agent Registry overview
• Model Armor overview
• Model Armor: Configure floor settings
• Integrate Model Armor with Agent Gateway
• Sensitive Data Protection overview
• Cloud Architecture Center: Choose a design pattern for your agentic AI system
• Cloud Architecture Center: Orchestrate security operations workflows
• ADK: Get action confirmation for ADK tools
• ADK: Safety and security for AI agents
• Gemini Enterprise: Workflow Builder overview
• Workflow Builder: Use human-in-the-loop steps
• Gemini Enterprise: Compare editions
• CX Agent Studio: Flow-based agents
• Dialogflow CX: Pages
• Agent Search product page
• Anthropic: Models overview

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.