Don't Give AI Agents Root. Let Them Open Pull Requests.

Would I give an AI agent root access to a production Kubernetes cluster? No. Would I let it open pull requests? Gladly.

That sounds like a contradiction until you look at where the real control point in a GitOps setup sits. It isn't the cluster. It's the path a change takes before it reaches the cluster.

Earlier this month Mauro Morales, a CNCF Ambassador, published Don't give AI agents root. Make them propose the next system state. on the CNCF blog. His core argument is simple: an agent should inspect the current state of a system and propose the next one. It should not apply that state itself. The proposal goes through the same software factory every human change goes through: review, CI, tests, build, signing, release, deployment.

One line from his post stuck with me: if you give an agent root and expect a well-written AGENTS.md to prevent an unrecoverable mistake, you are fooling yourself. The model is nondeterministic. You can't guarantee the outcome, so you have to guarantee the path instead.

His post focuses on the operating system layer and immutable hosts. I want to look at the same principle from the Kubernetes and GitOps side, because for many platform teams the boundary already exists. We just don't always enforce it properly for bots.

If you run Argo CD or Flux, this model is almost boring. The rule is already there: what is not in Git does not end up in the cluster. The controller reconciles toward the desired state in the repository, and drift gets corrected.

So the safe shape for an agent looks like this:

The agent becomes one more contributor. Its change is a diff that a human can read, CI can test and policy can reject. If it's wrong, you close the PR. If it was merged and turns out wrong, you revert a commit, and you know exactly which commit and which identity introduced it.

That traceability is the part people underestimate. It's not only about stopping bad changes. It's about knowing afterwards what changed, when and who or what proposed it.

Here is the sentence from Mauro's post that I think matters most: the agent's identity may propose, but it must not approve, merge, or change the pipeline. Otherwise you have just replaced root with root plus a few extra steps.

This is exactly where I see many real setups fall short. The pattern usually goes like this:

At that point the PR flow is theatre. The agent can propose a change, approve it, merge it and adjust the CI job that was supposed to catch it. Argo CD then faithfully syncs whatever landed on main. The cluster is protected by GitOps in theory and wide open in practice.

None of this needs new tooling. It's mostly configuration you probably already have, applied honestly to non-human identities:

The last point is one I keep coming back to in my own work. A gate that passes when it has missing data is not a gate. For agent-proposed changes that matters even more, because the volume of proposals can grow much faster than the attention of the reviewers.

I don't think the answer is to keep agents out of production work. They are genuinely useful at reading signals, correlating logs and proposing a fix faster than a tired on-call engineer at 3 a.m. The answer is to give them the same contract every engineer on the team already has: you can suggest anything, and the system decides what gets applied.

GitOps gave us that contract years ago. The job now is to make sure the bot account actually lives under it, instead of quietly sitting above it because it was quicker to set up that way.

So I'll ask the same question I asked on LinkedIn: how much is an agent allowed to do in your production environment today, honestly?