I Built a Read-Only kubectl So AI Agents Can't Break My Cluster

Last month I gave Claude access to one of our staging clusters. Within minutes it tried to kubectl exec into a pod and ran kubectl get secret -o yaml . Nothing bad happened — but it made me think: what if it had been production? So I built kubectl-ro . What it does It's a thin wrapper around kubectl that only allows read-only commands. You use it exactly like kubectl: kubectl-ro get pods -n kube-system # works kubectl-ro logs deployment/my-app # works kubectl-ro delete pod nginx # nope # ✘ BLOCKED: 'delete' is a mutating command That's it. If the command would change anything in your cluster, it gets blocked before kubectl ever sees it. Why not just use RBAC? You absolutely should use RBAC. But RBAC is server-side — it requires cluster admin setup, service accounts, role bindings. kubectl-ro is client-side. You install it, point your AI agent at it, and you're done. No cluster changes needed. Think of it as a seatbelt, not a replacement for airbags. It also protects secrets This was th