Skip to lesson

Google CloudProfessional Agentic Architect2026-095.1 Configuring agent security and governance

Cap agent reach with Principal Access Boundaries

Completed by the knowledge check

Learning objective

Apply Principal Access Boundary (PAB) policies to cap the maximum Google Cloud resources that an Agent Identity may reach.

Core idea

A PAB is a resource eligibility ceiling attached to principals. It limits where a principal can use supported permissions, even when an allow policy on an out-of-bound resource grants a role to that principal.

For a permission that the PAB enforcement version supports, use this mental model:

effective access = resource is PAB-eligible
                AND no deny policy blocks the permission
                AND an allow policy grants the permission

The PAB term cannot make the expression true by itself. A PAB does not grant a role or permission. It only makes listed resources eligible. IAM still evaluates applicable deny and allow policies. Google Cloud documents this evaluation order in IAM policy types.

This ceiling is valuable for an agent because model-directed behavior can select an unexpected tool or resource. A role granted later by another team cannot expand the agent beyond its PAB-eligible resource envelope when the requested permission is supported.

How it works

A PAB policy contains ALLOW rules that list eligible Resource Manager resources: organizations, folders, and projects. Listing a container makes it and its descendants eligible; it does not grant access to them. The policy also specifies an enforcement version, which determines the permissions that IAM can block. See the PAB policy structure and enforcement model.

Apply the ceiling in five steps:

  1. Define the resource envelope. Identify the smallest projects, folders, or organization that contains every Google Cloud resource the agent needs. Keep optional or future resources outside the boundary until the agent has a real requirement. Check each required permission against the enforcement version reference.
  2. Create the PAB policy. Add only those Resource Manager resources as eligible rules. Select an enforcement version deliberately, and confirm that it covers the permissions used by the agent.
  3. Bind the policy to the right principal set. A policy has no effect until a policy binding connects it to a principal set. Google Cloud supports a principal set containing the agent identities in a project’s trust domain. A binding condition can further select agent identities by principal.type or principal.subject.
  4. Check every applicable PAB. A principal can be subject to policies bound to its project, ancestor folder, or organization principal sets. Relevant PAB policies are additive: the final eligible set is their union. Remove or condition any broader policy that would reopen resources.
  5. Simulate, deploy, and test denial. Use Policy Simulator before creating the binding; it evaluates the PAB change, not the complete allow-policy configuration. Then test an allowed request and an intentionally out-of-bound request with a supported permission. Preserve at least one applicable PAB while replacing a boundary; with no applicable PAB, the principal becomes eligible for all Google Cloud resources.

The create and apply guide describes policy bindings, binding conditions, and simulation. The conditions attribute reference defines the supported agent-identity values.

Key distinctions and trade-offs

PAB versus allow policy: An allow policy answers, “Which permissions does this principal have on this resource?” A PAB answers, “Is this resource inside the principal’s possible reach?” You normally need both: a narrow allow grant inside a narrow PAB envelope.

PAB versus deny policy: A deny policy blocks named permissions on the resource where it is attached and its descendants. A PAB follows a principal and blocks supported permissions outside its eligible resource set. Use a PAB when the invariant is about the agent’s maximum reach, including resources administered by another team or organization.

PAB versus gateway or network controls: A PAB is an IAM decision for Google Cloud resources and supported permissions. It does not route traffic or limit calls authenticated to external SaaS systems with API keys or OAuth tokens. It also does not transfer to a tool backend that makes a new call as its own identity. Apply separate controls to those identities and paths.

Broad container versus precise access: A project-level PAB is stable as resources are created, but every resource in that project is eligible. PAB rules do not name individual buckets or datasets. Use resource-level allow and deny policies to narrow access within the eligible project.

Fixed versus automatically advancing enforcement version: A fixed version makes policy behavior predictable but requires planned upgrades to cover newly supported permissions. An automatically advancing version can broaden enforcement and cause unexpected denials. Google recommends managing version changes deliberately.

Architecture / decision scenario

A production invoice agent runs with a unique Agent Identity in agent-runtime-prod. It reads invoices from resources in invoice-data-prod, writes audit records to agent-audit-prod, and needs no other Google Cloud projects.

The security team creates one PAB that lists those three projects. It binds the policy to the agent-identity principal set for the runtime project and uses a binding condition to select the invoice agent. The team verifies that the chosen enforcement version covers the storage and logging permissions in the agent’s roles. Separate allow policies grant only the required read and write permissions inside the two eligible projects.

During simulation, the team discovers an organization-wide PAB that makes all projects in the organization eligible for every agent. Because PABs combine by union, adding the narrow policy alone would not create a narrow ceiling. The team updates the broad binding condition to exclude this agent, confirms that the narrow PAB remains applicable, and then applies the change. A test role on an unrelated analytics project still cannot give the agent access.

The narrow ceiling holds only once the organization-wide PAB no longer applies to the agent.

The narrow ceiling holds only once the organization-wide PAB no longer applies to the agentStarts at the organization-wide PAB and asks whether its binding condition excludes this agent. If not, its eligible set combines by union with the narrow PAB that lists three projects, and there is no narrow ceiling. If it does, the narrow PAB remains applicable, and a test role on an unrelated project cannot give the agent access.NoYesNarrow PAB liststhree projectsOrganization-widePABBroad bindingcondition excludesthis agent?Union: no narrowceilingNarrow PABremains applicableTest role cannotgive access

The result limits blast radius without pretending that the boundary grants access or covers external APIs. Gateway policy separately restricts the agent’s SaaS destinations.

Common exam traps

  • Treating a PAB rule as a permission grant.
  • Assuming multiple PAB policies intersect; their eligible resource sets form a union.
  • Binding a narrow PAB while leaving a broader ancestor binding applicable.
  • Assuming a PAB can block every permission without checking its enforcement version.
  • Removing the old binding before the replacement applies, which can create a period with no resource ceiling.
  • Expecting a PAB to select an individual bucket, control external APIs, or replace gateway and network enforcement.
  • Assuming the agent’s PAB limits a downstream request made under a tool backend’s different identity.

What to remember

  • A PAB caps where an Agent Identity can use supported permissions; it grants no permissions.
  • Effective access still requires an allow and must survive applicable denies.
  • Bind the policy to the intended agent principal set and inspect ancestor bindings.
  • Multiple applicable PABs add eligible resources by union.
  • Verify enforcement-version coverage and test both allowed and denied paths.

Knowledge check

References