## TL;DR
Give the agent a dedicated ServiceAccount, a Role (not ClusterRole) limited to one namespace, and only the verbs it needs on only the resources it needs. Never hand an agent cluster-admin or a wildcard Role; the blast radius of an agent with broad RBAC is every namespace at machine speed. Start narrow, widen deliberately, and audit what it actually uses.

## The query
```text
how to scope an agent's kubectl RBAC to one namespace
```

## Use this when
- An AI agent needs kubectl access
- Applying least privilege to automation identities
- Containing the blast radius of agent mistakes
- Auditing what an automation identity can do

## Not for when
- Human user access (different trust model)
- Multi-namespace operators the agent legitimately needs
- Cloud IAM roles (separate system)

## Steps

### Step 1: Create a dedicated ServiceAccount for the agent
The agent gets its own ServiceAccount in the target namespace, not the default one and not a shared automation identity. Dedicated identity means the audit log shows exactly what the agent did.
Expected output: a ServiceAccount whose entire purpose is this agent.

### Step 2: Write a Role limited to the namespace and needed verbs
Define a namespaced Role granting only the verbs the agent needs (often get, list, and maybe create/delete on specific resources like pods or jobs). No wildcards on resources or verbs; enumerate them. If the agent only reads, it gets read-only.
Expected output: a Role whose permissions you can read in one screen and justify line by line.

### Step 3: Bind with a RoleBinding, never a ClusterRoleBinding
Bind the Role to the ServiceAccount with a RoleBinding in the same namespace. Double-check there is no ClusterRoleBinding granting this account anything cluster-wide; one stray binding silently escalates everything.
Expected output: the agent's effective permissions confirmed as namespace-scoped via an auth check.

### Step 4: Verify with can-i before handing over the credential
Run auth checks as the ServiceAccount for allowed and denied actions: it can list pods in its namespace, it cannot list namespaces, cannot touch other namespaces, cannot escalate. Test the denials, not just the allows.
Expected output: allows pass, denials hold, documented.

### Step 5: Audit and tighten periodically
Review the API audit log for what the agent actually used. Permissions it never touches get removed; new needs get added deliberately with a reason. Agent capabilities evolve; the Role should evolve with them, by review, not by drift.
Expected output: a Role that matches the agent's real usage, reviewed on a schedule.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_11JQKGvUKagzcfY5ZZ1zJw