Kubernetes RBAC for AI Agents: Least-Privilege Patterns That Actually Matter

#devops #ai #kubernetes #security

Canonical URL:

https://infradecode.com/kubernetes-rbac-for-ai-agents-least-privilege-patterns/

Introduction:
Most teams bolt an AI agent onto their Kubernetes cluster and give it a ServiceAccount with cluster-admin because "it's just for diagnostics."

That's the mistake.

AI agents — K8sGPT, LangChain tools, Claude MCP, custom agents — are untrusted automation clients. They process logs, prompts, tool outputs, and user instructions. Any of those inputs can be manipulated via prompt injection.

If the agent can only read → prompt injection influences recommendations.
If the agent can mutate → prompt injection influences your cluster.

Here's the RBAC pattern I use in production to prevent that.
Section 1 — Core Principle

The Core Principle

Always use this pattern for AI agents:

ServiceAccount → Role → RoleBinding → Namespace

Never default to this:

ServiceAccount → ClusterRole → ClusterRoleBinding → Entire Cluster

Namespace isolation is your first security boundary.
Section 2 — Production RBAC YAML

Production RBAC YAML

apiVersion: v1
kind: Namespace
metadata:
name: ai-diagnostics
labels:

security.infradecode.com/purpose: ai-agent-diagnostics

apiVersion: v1
kind: ServiceAccount
metadata:
name: k8s-ai-diagnostics-agent
namespace: ai-diagnostics

automountServiceAccountToken: true

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: k8s-ai-diagnostics-readonly
namespace: ai-diagnostics
rules:

apiGroups: [""] resources:
- pods verbs:
- get
- list
- watch
apiGroups: [""] resources:
- pods/log verbs:
- get # Secrets intentionally excluded # pods/exec intentionally excluded # No mutation verbs granted --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: k8s-ai-diagnostics-readonly-binding namespace: ai-diagnostics subjects:
kind: ServiceAccount name: k8s-ai-diagnostics-agent namespace: ai-diagnostics roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: k8s-ai-diagnostics-readonly Section 3 — Verification Commands ## Verify With kubectl auth can-i

NS="ai-diagnostics"
SA="k8s-ai-diagnostics-agent"
IDENTITY="system:serviceaccount:${NS}:${SA}"

These should return: yes

kubectl auth can-i get pods --as="${IDENTITY}" -n "${NS}"
kubectl auth can-i list pods --as="${IDENTITY}" -n "${NS}"
kubectl auth can-i get pods --subresource=log --as="${IDENTITY}" -n "${NS}"

These should return: no

kubectl auth can-i delete pods --as="${IDENTITY}" -n "${NS}"
kubectl auth can-i get secrets --as="${IDENTITY}" -n "${NS}"
kubectl auth can-i patch pods --as="${IDENTITY}" -n "${NS}"
kubectl auth can-i impersonate users --as="${IDENTITY}"
Section 4 — Two Identity Model

Two Identity Model for Production

Don't combine diagnostic and remediation in one identity. Use two:

Diagnostic Agent
→ get, list, watch only
→ Explains issues. Never acts.

Remediation Controller
→ Narrow approved actions only
→ Requires approval gate, audit logging, and rollback path

This separation prevents prompt injection from becoming direct cluster compromise.
Section 5 — Three Mistakes to Avoid

The Three Mistakes to Avoid

Giving cluster-wide view access
Even read-only cluster access exposes namespace topology, workload relationships,
and metadata across all environments. For AI agents, this data becomes attack surface.
Allowing Secrets access
Secrets may contain DB credentials, API keys, cloud tokens, signing keys.
Even read-only access is dangerous. Provide sanitized error logs instead.
Adding mutation verbs for convenience
create, update, patch, delete turn a diagnostic assistant into an active cluster operator.
That is a completely different risk category.
Section 6 — TL;DR + Closing

TL;DR