dsh-kubectl-guard: A kubectl Context Safety Guard for DeepSeek Harness

What Does It Do?

dsh-kubectl-guard is a DSH plugin for DeepSeek Harness that gates kubectl commands by kubeconfig context. It solves the problem of an AI agent running destructive operations against a real cluster: irreversible verbs against a non-local cluster are denied outright, recoverable writes ask for approval first, and reads plus local clusters are left untouched. The plugin registers no tools of its own — it inspects the command argument of shell tool calls, so it covers whatever the agent runs. It is maintained by gengwg under the MIT license and was last updated in 2026-09.

Core Features

• Context-aware gating: delete, drain and evict are denied on non-local clusters, while apply, patch, scale and exec ask first, and get, describe, logs and top always pass.
• Shell-faithful context resolution: an explicit --context wins, then --kubeconfig, then an inline KUBECONFIG= assignment on the same command line, then the ambient environment.
• Local cluster allowlist: only contexts matching localContexts count as local; everything else, including an unreadable kubeconfig, is treated as production.
• Context name pseudonymization: showContextNames is off by default, so blocked-command messages expose a stable per-session pseudonym like ctx#4be1f92a instead of the real cluster name.
• Fail closed: anything unparseable, such as sh -c, command substitution or an unterminated quote, is treated as a mutation — denied if it contains an irreversible verb, asked otherwise.
• Dry runs pass: apply --dry-run=server counts as a read, giving the agent a way to show a change before asking for it.

How to Use This Plugin?

Once enabled in DSH there is nothing to invoke — ask the agent to do its normal work and the guard sits in the tool pipeline, inspecting the shell command before it runs. Typical scenarios: asking the agent to delete a stuck pod is denied with an explanation, rolling out a new deployment pops an approve/deny prompt in the UI, and querying failing pods in kube-system is unaffected. To turn the guard off for a single session, start the session with a patch that marks it disabled, without editing config files. Behavior is tuned through the config section, covering the localContexts allowlist, the binaries and guardedTools it watches, and whether real context names are shown.

How to Troubleshoot This Plugin?

If the guard loads twice after upgrading from 0.1.x, a manual insert entry left behind by the older plain-dependency install is still active; remove that entry from the config file as described in the official instructions. If a command is unexpectedly denied or questioned, check whether the current context matches the localContexts allowlist — unmatched contexts, including an unreadable kubeconfig, are treated as production.