What Kubernetes permissions would you actually give an AI agent?

A practical middle ground is a tightly scoped namespaced Role: allow read access to the relevant pods, deployments, and events; perhaps allow deleting pods for recovery; and allow only the narrowly required deployment patches for a rollout restart or rollback. I would grant nothing for secrets, RBAC resources, or cluster-scoped objects. Admission policies should enforce those boundaries so the system fails closed instead of relying on the agent to behave.

Logs are too late if the agent has already changed the wrong deployment or exposed a secret. I would combine audit logging with real-time admission controls and, for sensitive operations, a human checkpoint. For routine recovery, a short delay and fast alerting may be enough, but secrets, permissions, and cluster-wide resources should be blocked outright rather than merely recorded.

For configuration changes, I would avoid direct write access entirely. Let the agent prepare a change in version control and send it through the same review and deployment process used for human changes. Autoscaling can usually be handled by dedicated controllers rather than by giving the agent broad permissions. The exceptions are live, time-sensitive actions such as attaching an approved debug container or port-forwarding during an incident.

The identity holding the token matters as much as the RoleBinding. A broker outside the agent could issue short-lived credentials for one task and one exact action, such as deleting a pod in a particular namespace. It can deny requests for secrets, RBAC, and cluster-wide resources before Kubernetes ever sees them, while recording the intent and result immediately. That is stronger than giving the agent a standing token and hoping the audit log catches misuse afterward.

In a small home lab, full access can be surprisingly useful if the cluster is disposable and everything is backed up. I have let a local model inspect deployments, update images, read release notes, apply changes, check logs, and commit the resulting manifests. Git history, filesystem snapshots, and backups provide recovery options. That setup is reasonable for experimentation, but it is not a security model I would carry into a production environment; the agent may encounter a task that expands beyond its original scope and decide to use credentials for an unrelated operation.

I would not allow an agent to restart or roll back production workloads without a human approval step. Read-only access is fine, and a sandbox namespace could allow it to try commands automatically, but production changes should initially be suggestions or reviewed actions. An audit log is useful for accountability, not as a substitute for preventing a bad command.