dsh-kubectl-guard

Letting an agent type kubectl commands is convenient until a stray delete pod or scale --replicas=0 lands on a production cluster with no undo. dsh-kubectl-guard registers no tools of its own; it sits in the shell tool pipeline and inspects every command string the agent is about to run, applying a three-tier verdict based on the kubeconfig context and the severity of the verb. Irreversible operations on non-local contexts (delete, drain, evict, apply --prune, replace --force, scale --replicas=0) are denied outright; recoverable writes such as apply, patch, and exec prompt for UI approval first; reads (get, logs, top) and --dry-run=server always pass, and local contexts are entirely ungated.

Context resolution mirrors shell precedence: an explicit --context wins, then --kubeconfig, then an inline KUBECONFIG assignment on the same command line, and finally the ambient environment. This prevents KUBECONFIG=/path/to/prod kubectl delete ... from being judged against whatever your shell happened to point at. Unparseable input (sh -c, command substitution, an unterminated quote) is treated as a mutation; unknown verbs ask rather than allow. The failure direction is always safe. By default the cluster name is replaced with a per-session pseudonym (ctx#4be1f92a), so neither the agent nor the LLM provider ever sees the real cluster name in a denial message.

It is aimed at engineers who use DeepSeek Harness to operate K8s daily and want the agent to keep full read-write capability without a hallucinated delete taking down production. The guard is a seatbelt against a confused agent, not a sandbox against a hostile one: if the binary name is hidden behind an environment variable or a base64 round-trip, the filter simply cannot see it. For stronger isolation, revoke the cluster credential rather than filtering the command string. Coverage is kubectl only today; helm, argocd, and flux are not yet in the verb table, but the table in src/verbs.js is pure data, so adding them is a one-line edit.