agent serviceaccount "forbidden: cannot list resource": RBAC debugging
Debugs RBAC forbidden errors for AI agent service accounts. Use when agents get forbidden listing or getting resources, when agent permissions seem right but fail, or when auditing agent access. Not for human user RBAC.
TL;DR
An agent's "forbidden" error means its ServiceAccount lacks the verb on the resource in that namespace (or cluster-wide). Debug exactly like human RBAC: identify the service account, check its RoleBindings, and test with auth can-i as that account. The usual miss is a RoleBinding in the wrong namespace or a Role missing the specific verb/resource combination the agent needs.
The query
agent serviceaccount "forbidden: cannot list resource": RBAC debuggingUse this when
- AI agents get forbidden errors on API calls
- Agent permissions look right but fail
- Auditing what an agent can actually do
- After RBAC changes
Not for when
- Authentication failures (not forbidden)
- Human user access issues
- Cloud IAM errors
Steps
Step 1: Identify the agent's service account and namespace
Confirm which ServiceAccount the agent authenticates as and in which namespace it operates. Agents using the default service account inherit whatever that account has, which is often nothing. Expected output: the exact identity (system:serviceaccount:ns:name) known.
Step 2: List its bindings
Show all RoleBindings and ClusterRoleBindings referencing the account. A missing binding is the most common cause; a binding in the wrong namespace is the second. Expected output: the bindings enumerated, gaps visible.
Step 3: Test with auth can-i as the account
Run authorization checks impersonating the service account for the exact verb and resource. This is ground truth: it evaluates the real RBAC graph, not your mental model of it. Expected output: the denial confirmed and precisely scoped.
Step 4: Fix the Role, not just the binding
If the binding exists but the verb is missing, update the Role to include the needed verbs and resources. Grant the minimum: the specific verbs on the specific resources in the specific namespace. Expected output: the can-i check passing with least privilege.
Step 5: Re-test the agent's actual call
Have the agent retry its exact failing call. RBAC changes take effect immediately, but cached client-side discovery can confuse the retest; retry the real operation, not just can-i. Expected output: the agent's workflow succeeding with the corrected permissions.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_qF9iPSkhseLw19FvIW8B7Q