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

Ajey kulkarni — Mon, 13 Jul 2026 07:03:35 +0000

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

Use namespace-scoped Roles, never ClusterRoleBinding for AI agents
Grant only get, list, watch on required resources
Deny Secrets, exec, impersonate, and all mutation verbs by default
Use separate identities for diagnostic vs remediation workflows
Always verify with kubectl auth can-i after applying

Full post with complete YAML and verification checklist on InfraDecode:
https://infradecode.com/kubernetes-rbac-for-ai-agents-least-privilege-patterns/

What RBAC patterns are you using for AI agents in your cluster?
Drop it in the comments — curious what others are doing differently

AI Agents for DevOps in 2026: Tools That Are Actually Worth Using

Ajey kulkarni — Fri, 10 Jul 2026 13:56:55 +0000

I've been testing a bunch of AI tools in my Kubernetes workflow over the past few months and wanted to share what's genuinely changed my day-to-day vs what's just marketing noise.

What's actually working:

K8sGPT — scans your cluster and explains issues in plain English. Saved me a lot of time on pod crash debugging. Open source, worth trying.
AI-assisted incident triage — tools that correlate logs + metrics and surface root cause faster than manual grep-ing through Kibana
Natural language infra provisioning — still early but some teams are running Terraform via prompts in CI pipelines

What's still overhyped:

Fully autonomous remediation without human approval (too risky in prod)
AI writing your Helm charts from scratch (output needs heavy review)

Wrote a longer breakdown on my blog if anyone wants the full list with tool comparisons: https://infradecode.com

Curious what tools others are actually running in production — anything I missed?****

DEV Community: Ajey kulkarni