5.2 Agent Identity, Principal Access Boundaries (PAB) & OAuth 2.0
1. Key Concept Definitions: The Zero-Trust Identity Stack
Section titled “1. Key Concept Definitions: The Zero-Trust Identity Stack”1. Managed Agent Identity
A verifiable, keyless SPIFFE cryptographic workload identity assigned to each individual agent. Eliminates shared service accounts and static JSON keys while enabling per-agent Cloud Audit Logs.
2. Agent Identity Auth Manager
Manages OAuth 2.0 user delegation flows, consent redirects, encrypted token caching, and automatic refreshes so tools execute strictly with the logged-in human user’s permissions.
3. Principal Access Boundary (PAB)
Defines the maximum set of Google Cloud folders/projects an agent principal is eligible to access. Even if someone grants an IAM Allow role outside the PAB, access is blocked!
4. IAM Deny Policy
An explicit permission veto attached to an Organization, Folder, or Project. Always overrides any IAM Allow grant (even Project Owner) to block dangerous actions like deleting audit logs.
2. Interactive Identity, OAuth 2.0 & Unified Policy Evaluation Explorer
Section titled “2. Interactive Identity, OAuth 2.0 & Unified Policy Evaluation Explorer”Switch between the 3 Identity & Access Modes below and click the 4 stages to trace OAuth 2.0 User Delegation, Unified Policy Evaluation (PAB -> IAM Deny -> IAM Allow), and Defense-in-Depth (PAB + VPC-SC):
3. Real-World Deep Dive: Common Identity & PAB Brain-Twisters
Section titled “3. Real-World Deep Dive: Common Identity & PAB Brain-Twisters”| Architect Question | How It Works Under the Hood in Production |
|---|---|
“If a Principal Access Boundary (PAB) says an agent is eligible for the Retail-Support folder, why is the agent STILL blocked from reading a Cloud Storage bucket in that folder?” |
PAB is a filter, not a grant! A Principal Access Boundary only defines the outer perimeter of eligibility. Effective access requires BOTH PAB eligibility AND an explicit IAM Allow role (such as roles/storage.objectViewer) on that bucket! |
| “How does an ADK tool know which OAuth 2.0 token to pass when 500 users are chatting with the same agent container simultaneously?” | Session-Scoped Token Resolution via Auth Manager: When a user logs in, their session is bound to their authenticated user_id. Inside the tool execution, Agent Identity Auth Manager looks up the encrypted OAuth 2.0 token specifically bound to that invocation’s user_id—never mixing tokens across concurrent users! |
| “When should I use PAB vs. IAM Deny vs. VPC Service Controls?” | PAB: Restrict where an agent identity is allowed to operate (e.g., Dev folder only).IAM Deny: Block specific dangerous permissions (e.g., deleting logs/KMS keys) regardless of role. VPC-SC: Draw a network/data exfiltration perimeter around sensitive resources (e.g., Prod BigQuery). |
4. Identity & Access Control Reference Matrix
Section titled “4. Identity & Access Control Reference Matrix”| Security Control | Primary Target | What It Prevents | Architectural Trigger / Use Case |
|---|---|---|---|
| Dedicated Managed Agent Identity | Individual agent workload | Blast-radius spread across co-located agents & static service account key leaks. | “Isolate 4 agents sharing a default service account,” “per-agent audit trail.” |
| Agent Identity Auth Manager (OAuth 2.0) | User-delegated tool invocations | Confused Deputy attacks (agent tricked into accessing User B’s data for User A). | “Execute trades/tickets on behalf of logged-in user,” “manage OAuth consent & token refresh.” |
| Principal Access Boundary (PAB) | Principal resource eligibility | Accidental IAM Allow grants giving an agent access to out-of-scope folders/projects. | “Ensure Customer-Support agents are never eligible to access R&D folder even if granted IAM Allow.” |
| IAM Deny Policy | Specific IAM permissions | Privileged principals (even roles/owner) executing destructive actions. |
“Ensure no agent can ever delete Cloud Audit Logs or disable KMS keys.” |