What actually stops KubeIntellect from deleting something important?

[MSKazemi]

Every "AI for Kubernetes" tool says it is safe. I want to know what specifically stops this thing from deleting a production StatefulSet because an LLM hallucinated a root cause.

Concretely:

• Can it run mutating commands at all, or is it read-only?
• If it can, what happens between "the model decides to act" and "the cluster changes"?
• What happens if I run it against a production cluster and walk away?

[MSKazemi]

Good question to be sceptical about, and the honest answer has four separate layers rather than one "safe mode" switch. None of them relies on the model behaving well — that is the design premise.

1. It can mutate, and every mutating path stops for a human

It is not read-only. That is the deliberate difference from read-only diagnostic tools: it can scale, restart, patch and delete. But every mutating command passes through one chokepoint that requires an explicit human approval in the same session — you type yes or /approve. There is no "the model was confident so it proceeded" path.

This applies to every role, including superadmin. From v4/docs/security.md § 2:

Even superadmin and admin users cannot execute destructive commands without explicitly typing yes or /approve in the same session.

2. Role-based limits sit underneath that, and they refuse before the prompt

Operation	superadmin	admin	operator	readonly
get, describe, logs, top, events	✅	✅	✅	✅
apply, scale, patch, create, run, exec	✅ HITL	✅ HITL	✅ HITL	❌ Blocked
delete, drain, replace, taint	✅ HITL	✅ HITL	❌ Blocked	❌ Blocked
Writes to infrastructure namespaces	✅ HITL	❌ Blocked	❌ Blocked	❌ Blocked

A readonly key cannot reach an approval prompt at all — the request is refused before one is shown. So "hand it a readonly key" is a real answer to your production question, not a euphemism.

3. Two blocklists the agent cannot argue with

Independent of role and of the model:

KUBECTL_BLOCKED_NAMESPACES=kubeintellect,monitoring,kube-system,kube-public,kube-node-lease,ingress-nginx,cert-manager
KUBECTL_BLOCKED_RESOURCES=secret,secrets,serviceaccount,serviceaccounts

superadmin bypasses the namespace block. Nothing bypasses the resource block — Secrets and ServiceAccounts stay shielded for every role including superadmin.

This is enforced in the application, before the Kubernetes API call and before the approval prompt. That layering is deliberate: cluster RBAC controls what the ServiceAccount can do; the blocklist controls what the agent is allowed to ask for, so you get a clear refusal in your session instead of an opaque API error. Cluster-side RBAC is still the outer boundary — cluster-exec is off by default (rbac.allowExec: false).

4. "Run it and walk away" — the autonomy ladder, default A1

This is the part of your question I would most want answered too. The watchtower can run investigations unprompted, and its level decides what that means (v4/docs/autonomy.md):

Level	What it does
A0	Logs the finding. No LLM investigation.
A1	Default. Investigates and publishes a report. No mutations.
A2	May also propose exact fix commands — does not execute destructive ones.
A3	Executes the fix without approval — only for (playbook, namespace) pairs on an explicit allowlist, then post-verifies with a fresh read.

The default is A1: it investigates and reports, and never touches the cluster. A3 requires both that the namespace is set to A3 and that the specific playbook/namespace pair is on AUTONOMY_A3_ALLOWLIST, which ships empty. With an empty allowlist, A3 behaves like A2. So auto-fix is not something you can end up in by accident — it takes two deliberate configuration acts naming the exact failure mode and the exact namespace.

You can also set levels per namespace: AUTONOMY_NAMESPACE_LEVELS=prod=A0,dev=A2.

What I would actually do for a production cluster

1. Start with a readonly key. You get the full diagnostic value with mutation structurally impossible.
2. Leave autonomy at A1 and leave the A3 allowlist empty.
3. Keep rbac.allowExec: false (the default).
4. If you later want auto-fix, enable it for one playbook in one non-production namespace and read the digest for a while first.

Where I would push back on my own answer

The gate is procedural, not a proof: it guarantees a human sees and approves each mutating command, not that the human reads it carefully at 3am. It reduces "the AI did something surprising" to "I approved something I did not fully read", which is a better failure mode but not zero. The dry-run diff exists to make that approval meaningful — judge it on whether the diff is actually legible.

And LLM answers can be wrong. That is the entire reason the gate exists, rather than something the gate makes irrelevant.

Related: v4/docs/security.md for the full model, and #52 if you want to push on where this goes next.