Lars Winstand

Posted on Jul 24 • Originally published at standardcompute.com

I thought the safe agent rollback strategy was “don’t touch Kubernetes” and then I saw this OpenClaw + Argo CD setup

#devops #ai #gitops #kubernetes

A lot of teams are stuck between two bad ideas.

Idea #1: give an agent broad Kubernetes access and hope GPT-5, Claude, or whatever model you picked doesn’t do anything dumb on Friday night.

Idea #2: ban agents from infra completely and keep waking humans up to grep logs, diff manifests, and remember version bumps.

I think both are wrong.

The safest pattern I’ve seen lately came from a thread on r/openclaw:
https://reddit.com/r/openclaw/comments/1v4rkpv/does_anyone_else_manage_their_kubernetes_cluster/

The short version:

OpenClaw gets read-only access to cluster state and logs
secrets are excluded
OpenClaw can open pull requests
Argo CD still deploys from Git
humans still review and merge

That is a much better rollback story than “let the agent freestyle in prod.”

The key idea: don’t give the agent production write access

The line from the thread that mattered was this:

“I then added an openclaw with an operator (openclaw-rocks) to the cluster and gave it a service account that can read state and logs (except secrets) to debug and rights to make pull requests.”

That’s the architecture.

Not:

kubectl apply from the agent
direct patching of live Deployments
shelling into production nodes because the model sounded confident

Instead:

read from Kubernetes
write to Git
let GitOps handle deployment

That split is everything.

If OpenClaw proposes a bad change, you get:

a diff
a review step
branch protection
a revert path
an audit trail

If the agent mutates the live cluster directly, rollback gets ugly fast.

What read-only Kubernetes access actually looks like

This is the boring part, which is why it’s the useful part.

A minimal RBAC role can be tiny:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

You can expand from there carefully.

For example, if you want an agent to inspect logs and events without write access:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: openclaw-readonly
rules:
- apiGroups: [""]
  resources: ["pods", "services", "events", "configmaps"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets", "statefulsets", "daemonsets"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get"]

And then bind that role to a dedicated service account:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: openclaw-readonly
  namespace: production
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: openclaw-readonly-binding
  namespace: production
subjects:
- kind: ServiceAccount
  name: openclaw-readonly
  namespace: production
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: openclaw-readonly

That is enough for an agent to be useful without becoming dangerous by default.

What an agent can still do with read-only access

A lot more than people think.

With get, list, and watch, OpenClaw can:

inspect failing Pods
read container logs
correlate Events with restarts
compare live objects to Git manifests
detect drift
suggest version bumps
summarize cluster health in Slack or Discord
open a PR with a proposed fix

That’s not “autonomous SRE replaces the platform team.”

That’s a decent on-call assistant.

And honestly, that’s the level of autonomy most teams should want first.

Read-only is not the same thing as safe

This is the part people hand-wave.

Read-only access still exposes a lot:

resource names
image tags
error messages
event history
stack traces
environment references
sometimes customer identifiers if your logs are messy

So no, read-only is not harmless.

If you do this, you still need:

secret exclusion
log redaction
namespace scoping
a dedicated service account
a boring RBAC review process

The real security question is not “which model are we using?”

It’s:

what can the agent read?
where can the agent write?

That’s the actual control plane.

Why PR review is doing most of the safety work

One commenter in that same thread said:

“the manual review step is doing more work than people give it credit for. my openclaw had PR rights to a repo last year and the merge queue caught more bad output than i expected.”

That matches my experience.

The merge gate is not ceremony.

It catches stuff like:

a Helm value that is technically valid but wrong for your environment
a Kustomize patch with the wrong selector
an image bump that skipped a migration note
a resource request that will starve another workload
a “cleanup” refactor that breaks naming conventions

If the agent only writes PRs, your rollback strategy is obvious:

git revert <commit>
git push origin main

Then Argo CD reconciles the cluster back to the last good state.

That is dramatically better than trying to reconstruct what an agent did directly against a live cluster.

The GitOps part matters more than the agent part

Argo CD is what makes this sane.

If Git is the source of truth, then production changes happen through reviewed manifests.

Typical setup:

argocd app set my-app --sync-policy automated
argocd app set my-app --self-heal

That gives you:

automated sync from Git to cluster
drift correction when live state diverges
a clean deployment path tied to commits

But Argo CD is not magic.

If a bad PR gets merged, Argo CD will faithfully deploy the bad change.

So the safety model is:

agent reads cluster state
agent proposes a Git change
human reviews the diff
merge happens
Argo CD syncs
rollback is a Git revert

That’s the important sequence.

A practical event flow with Forgejo

The sneaky interesting part of the Reddit setup was Forgejo.

The original post described a flow where OpenClaw reacts to Git events, writes code or config changes, and opens PRs for review.

That’s a very practical way to wire an agent into infra work.

For example, a Forgejo Actions workflow can react to pull requests and issues:

on:
  pull_request:
    types: [opened, synchronize, reopened]
  issues:
    types: [opened, edited, labeled]

Now imagine this loop:

a deploy check fails
a label gets added to an issue or PR
OpenClaw inspects cluster state and logs
OpenClaw comments with findings or opens a fix PR
a human reviews and merges
Argo CD deploys from Git

That is a real operating model.

Not a demo.

Not “AI DevOps agent” theater.

Just a clean workflow with clear boundaries.

Why I would not start with direct Kubernetes MCP write access

You can absolutely use a Kubernetes MCP server directly.

And if your team needs broad operations across clusters, Helm, exec, metrics, events, and CRUD access, it can be the right tool.

But the blast radius is much larger.

Here’s the tradeoff as I see it:

Approach	What it optimizes for
Read-only OpenClaw + GitOps PR flow	Safer debugging, drift detection, and proposed changes with human review
Direct Kubernetes MCP Server access	Faster intervention and richer cluster operations, but much higher permission risk
Argo CD as deployment control plane	Git stays the source of truth and rollback stays simple

If your goal is “let the agent help without becoming root in production,” the OpenClaw + PR + Argo CD pattern is the better default.

A minimal rollback strategy for agent-driven infra changes

If you’re setting this up, I’d keep the first version painfully simple.

1. Give the agent read-only cluster access

Only what it needs:

Pods
logs
Events
Deployments
maybe ConfigMaps
no Secrets
no write verbs

2. Give the agent PR rights, not cluster write rights

It should be able to:

open pull requests
leave comments
request reviews
maybe update labels

It should not be able to deploy directly.

3. Protect your main branch

Use branch protection so merges require review.

At minimum:

required review
CI checks
restricted direct pushes

4. Let Argo CD deploy from Git

Keep live changes out of band.

Git should be the deployment API.

5. Test rollback before you need it

Actually rehearse this:

git revert <bad-commit>
git push origin main
argocd app get my-app

If rollback depends on memory during an incident, you don’t have a rollback strategy.

Where Standard Compute fits if you’re running agents like this

One thing this Reddit pattern gets right is that useful agents do a lot of background work.

They inspect logs.
They summarize cluster state.
They compare manifests.
They draft PRs.
They react to failed checks.
They post updates to chat.

That means they make a lot of model calls.

If you’re running OpenClaw, n8n, Make, Zapier, or custom agent workflows all day, per-token billing gets annoying fast. People start rationing runs, trimming context too aggressively, or turning off useful automation because every loop feels billable.

That’s the reason Standard Compute is interesting for this kind of setup.

It gives you:

unlimited AI compute for a flat monthly price
an OpenAI-compatible API
drop-in support with existing SDKs and HTTP clients
dynamic routing across GPT-5.4, Claude Opus 4.6, and Grok 4.20

For agent-heavy workflows, predictable cost matters more than people admit. If your infra assistant is supposed to run constantly, “token anxiety” is a pretty bad operating constraint.

More here:
https://standardcompute.com

My take

I don’t trust “full autonomous infra engineer” setups.

I do trust systems where:

the agent can observe
the agent can propose
Git records the change
humans approve it
Argo CD deploys it
rollback is one revert away

That’s why this OpenClaw setup stood out.

It’s not flashy.

It’s just honest about where safety comes from.

And for production infrastructure, boring is usually the right answer.

DEV Community