The fear is reasonable: an AI with unsupervised access to production is a bad idea. KubeIntellect is built so that never happens. It can diagnose freely, but it cannot change your cluster without a human approving the exact action first. Here is the security model, from the outside in.

1. Read-only by default

Diagnostic reads — get, describe, logs, top, events — run automatically. Nothing is changed while KubeIntellect is just answering questions. For read-only use it needs only read permissions through your existing kubeconfig; no cluster-admin, no in-cluster agent.

2. Human-in-the-loop approval on every change

Every mutating action — scale, restart, patch, apply, exec, delete — pauses and waits for you. You see the exact command and approve or deny it before anything touches the cluster. The workflow freezes during the wait, so approval can come seconds or hours later. A small set of especially destructive operations (delete namespace, delete a PersistentVolume, drain a node) always require confirmation, even in automated modes.

3. Role-based access control

Access is scoped by API-key role: read-only keys can only read; operator keys can create/scale/patch/exec with approval but cannot delete or drain; admin keys can perform all writes with approval. You hand out the least privilege each person or automation needs.

4. Secrets are off-limits

Secrets and ServiceAccounts are blocked for every role, enforced before any command runs — the agent cannot read or exfiltrate credentials, by design. Sensitive namespaces (kube-system, cert-manager, ingress-nginx, the monitoring stack, and KubeIntellect’s own) are protected out of the box.

5. A hardened command layer

Commands don’t go through a shell. They’re parsed, shell-injection metacharacters are rejected, YAML is validated, verbs are checked against the caller’s role, protected namespaces and resources are blocked, and risky operations are classified and gated — all before execution. Output is capped so a runaway query can’t flood anything.

6. An auditable trail

Decisions and actions are recorded in order, so you can reconstruct exactly what happened for a postmortem or a compliance review. Because every change required a human approval, there’s always an accountable decision behind it.

Safe enough to be peer-reviewed

This isn’t a marketing posture. The architecture — including the human-in-the-loop confirmation on all mutating operations — was published and peer-reviewed in the Journal of Grid Computing (2026). You can read the paper and connect a cluster in read-only mode to see for yourself:

pip install kube-q kq "what's unhealthy in my cluster right now?"   # read-only, changes nothing