## 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
```text
agent serviceaccount "forbidden: cannot list resource": RBAC debugging
```

## Use 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