Kubernetes RBAC is not an AI agent’s permission model

Hand an AI agent a kubeconfig and you have answered one question: what may this identity do in this cluster. Kubernetes RBAC answers it well. It is not the only question an agent raises, and the others are the ones that decide whether you sleep through the night.

What RBAC answers

A Role or ClusterRole lists verbs on resources; a binding gives them to a user, a group or a ServiceAccount, in a namespace or everywhere. patch deployments in prod is a complete, enforceable sentence, and the API server checks it on every request. Nothing in this post replaces that.

What RBAC cannot express is everything around the verb:

Which change. kubectl rollout restart is a patch that adds an annotation to the pod template. So is changing the image. RBAC sees one verb, so an identity allowed to restart a deployment is allowed to re-image it.
Until when. A token pasted into an agent’s configuration works until someone rotates it.
Who asked. If five agents and three people share one ServiceAccount, the cluster’s audit log names the ServiceAccount.
Whether a person said yes. RBAC allows or denies; it has no “allowed, after review”.

Two layers, not one

In Subnomic the cluster’s own RBAC still has the last word. The Kubernetes agent runs inside the cluster with its own ServiceAccount, and every request through Subnomic reaches the API server as that account. Its RBAC is the ceiling: nothing a person or an AI agent does through Subnomic can exceed what you granted the agent. The proxy also drops Impersonate-* headers, so a caller cannot borrow identities the account might be allowed to impersonate.

Inside that ceiling, a second layer decides what each caller may do. An AI agent never gets the kubeconfig. It gets an agent credential, and every call it makes is checked in order:

Capabilities. kube.read and resource.read to look; resource.write to restart, scale, re-image or apply; resource.delete, separately, to delete. The tools the agent sees are only the ones its capabilities allow.
Targets. The clusters this credential names, not every cluster in the workspace.
The person behind it. A credential never holds more than the person who created it, and that is checked again on every request, so a demoted author takes their agents down with them.
An expiry. Between 7 and 360 days. There is no credential without one.
Guardrails. Rules matched against the Kubernetes change itself, before it runs. The first match decides: allow, deny, or require approval.

What that buys you that RBAC alone does not

The restart versus re-image problem goes away, because the tools are different calls. rollout_restart and rollout_set_image are separate tools, and a guardrail can tell them apart by what the change does, not by its verb. In a supervised Runa run, a restart can be approved by a person and an image change cannot be approved at all; it stays with a person at a keyboard.

The who asked problem goes away, because attribution lives on the Subnomic side. The cluster’s audit log will show the agent’s ServiceAccount, as it should; the workspace activity log shows which credential, created by which person, made which call, with its arguments.

The did anyone say yes problem gets an honest answer instead of a reassuring one. An external agent over MCP has no way to stop and ask, so a guardrail that requires approval refuses its call. A person approves inside the console, in a supervised run or at a workflow’s approval step, never by an agent rephrasing the request.

Where to start

Give the cluster agent’s ServiceAccount the most you would ever want done through Subnomic, and no more. A read-only ClusterRole is a fine first week.
Give each AI agent its own credential, read-only, on the clusters it needs, for 30 days.
Write a guardrail for the changes you would want to be asked about, then grant resource.write. Grant resource.delete last, if ever.
Run rbac_audit, one of the read-only security tools, against the cluster to see which of its own bindings deserve a second look.

Every capability and the tools each one unlocks are in Agent access (MCP), the rule syntax in Guardrails, and an investigation that uses all of it in a Kubernetes incident, step by step.