There is an AI agent somewhere in your Kubernetes environment right now, running commands directly against your clusters, using a human’s actual credentials. Really, and its likely been that way for several months already.
The people wholly embracing the Agentic AIOps wave are the platform team, the DevOps folks on triage, and the developers supporting their own apps, and these also so happen to be the people whose assigned access has the widest blast radius on the platform. The agents therefore are effectively highly permissioned by default, which is a security position of implicitly trusted. This flies in the face of normal “permission of least privilege” operational models.
Like it not, this is the current reality of Agentic AIOps against a container platform, and given the meteoric rise in popularity of agentic harnesses, its very much something running inside every Kubernetes equipped enterprise today.
GitOps was a “must” until it wasnt…
The Kubernetes community already made it very clear that GitOps and Kubernetes go hand in hand, and that directly manipulating a cluster is a fools-errand. Go to any conference, listen to any talk, read any blog that mentions Kubernetes and the common thread is that no “serious” Kubernetes team in the world would let a junior engineer type kubectl apply against production, because it would fail the code review, fail the change management process, and fail the intuition of every senior engineer on the team. Argo, Flux, and the CNCF GitOps Working Group exist because we, collectively, believed direct-apply was wrong, and that every change should be reviewable in Git, reproducible from what is in the repo, and rollback-able through git revert.
Then the AI turned up, and MCP servers for the plethora of CNCF discrete tools made their appearance. These were all loaded into an engineers AI agent with glee. What then happens is that the AI agent runs countless kubectl commands directly against the cluster; it does not open a pull request, it does not wait for a peer reviewer, and it does whatever it decided to do in the moment it decided to do it, at machine speed. What you have there is not ClickOps, because ClickOps at least has a human doing the clicking; it is ClickOps performed by a probability distribution, and the same team that would not accept a manual kubectl apply from a junior engineer is now accepting it from a language model with three seconds of context. Did we all quietly decide the discipline stopped applying the moment the operator was not a person, or did we just not notice we had made the exception?
AI has a nasty habit of never providing the same output for the same input, and that means trying to trace a change becomes infinitely more problematic; reproducibility matters. Arguably more important is the ability to roll a change back via a git-revert. Why? Well try asking AI to join the incident call to explain their thinking behind a change made 5 changes ago!!
The market has made peace with the exception
You would think, given how visible this problem is, that at least one product on the market would have built its answer around the discipline the community already believes in; almost none have. The horizontal MCP gateways (Kong, Solo’s agentgateway, Microsoft, IBM Context Forge, and the growing list Gartner is now predicting every API gateway vendor will ship) will allowlist tools and audit calls, and will happily let the write tools through, because the gateway does not know what a Kubernetes cluster is. The just-in-time credential vendors (Teleport, hoop.dev, StrongDM) will shorten how long the token is valid, and the AI still runs kubectl apply against production with it. The Kubernetes-native agent runtime (kagent, the closest CNCF-adjacent answer) will pause on a “requireApproval” tool call and ask a human to click approve, and the moment the human clicks, the change goes direct to the cluster. The kill switch and control tower vendors (Straiker, Zenity, Palo Alto’s Secure AI Agents) will shut the agent down after it has already applied the change. The reference implementations that actually take GitOps seriously (kubemend, gitops-drift-agent, Cast AI’s agentic runbooks) are single-purpose autonomous agents rather than a governance layer for the general case. Every one of these products is legitimate in its own frame; none enforces GitOps as the mandatory path for AI-originated changes, and most treat that as a feature rather than a gap.
What a real answer would have to look like is not mysterious. Every primitive it needs already exists. Kubernetes has read only RBAC roles, we already have humans peer reviewing manifests in GitHub, and we have GitOps reconciliation to deliver changes to environments. The only problem is forcing AI to use these primitives properly rather than going around and making direct changes to prod.
All agentic operations must go via a Kubernetes aware gateway, so that it can intercept “change” at the source rather than let them through. The gateway has to issue short-lived read-only credentials with a rationale the model itself supplies. It has to intercept every write intent and open a pull request against the enterprises GitOps repository, with no exception path. It has to apply approved changes through GitOps reconciliation, so the rollback is git revert. And it has to have an authoritative kill switch that revokes the credentials it issued, rather than an after-the-fact network approximation. None of that is novel individually; the missing product is the one that composes all of it, opinionatedly, and refuses direct-apply as a path at all.
Every CISO I talk to is being asked to say yes to putting AI into operations; they know the productivity story is real, and they also know that when the change goes wrong they will be the person in the room who allowed it in. Every platform lead is being asked the same question from the other side; they built the GitOps discipline, they defended it through three cycles of ClickOps advocacy, and they are watching their own team’s AI tooling bypass it. The honest answer to both is the same one the community reached the first time around; the discipline was right for humans, and it is more right for AI, and any product positioning itself as “AI governance for Kubernetes” without enforcing GitOps as the only change path is asking you to abandon the change control you already had.
A product like this does not exist yet because the product needs opinionated integration between three worlds that are usually owned by three different vendors. The agent-facing surface, the Kubernetes management surface, and the GitOps runtime have historically been three separate roadmaps, and a product that enforces AI-originated changes as PRs that a human merges and a reconciler applies has to own all three at once. No vendor with only one of the three can build it, and the vendors with two are not the same vendors…. until now.
That shape of product is what we are building at Portainer, and it will be called Portainer-Command. Keep an eye out for it; we will have more to say at KubeCon in Salt Lake City this year, and if any of the pattern above is familiar to you, that is where you will find us.
Disclosure, I work on operatex.dev. Agents inheriting a person’s full access is the real problem here. We keep ours read-only, it investigates and explains, and a person applies the change.