Introduction

In a DeepSeek Harness (DSH) environment, large models may directly execute irreversible operations such as kubectl delete or apply. If these commands target non-local production clusters, the risk is extremely high. Existing approaches usually rely on manual review or complex prompt engineering, which is inefficient. As a policy plugin, dsh-kubectl-guard directly intervenes in the tool-call chain and intercepts or confirms commands before execution based on kubeconfig context.

What Is This?

This is a DeepSeek Harness policy plugin maintained by gengwg. It restricts kubectl usage by inspecting the kubeconfig context: it denies irreversible operations (such as delete) against non-local clusters, asks for confirmation on recoverable write operations (such as apply), and allows read operations and operations on local clusters.

Core Features

  • Intercepts kubectl commands based on kubeconfig context
  • Denies irreversible operations against non-local clusters (for example, delete)
  • Requests confirmation for recoverable write operations (for example, apply)
  • Allows read operations and operations on local clusters
  • Inspects command parameters in Shell tool calls

Installation and Enabling

This plugin depends on pnpm, which DSH invokes to install it.

  1. Run the installation command:
    dsh plugin --profile web add dsh-kubectl-guard
  1. After installation, the plugin is automatically added to the bundle stack. Restart DSH to activate it.

Typical Usage

This plugin does not register new tools; instead, it intercepts the command parameter in Shell tool calls.

  • Intercepted (irreversible operation + non-local cluster):
    > delete the stuck nginx pod
    Error: kubectl-guard: ‘delete’ is irreversible and ctx#4be1f92a is not a local cluster. Denied.

  • Prompted (recoverable write + non-local cluster):
    > roll out the new deployment
    kubectl-guard: ‘apply’ writes to ctx#4be1f92a, which is not a local cluster.
    [approve] [deny]

  • No impact (read operation):
    > what pods are failing in kube-system?
    kubectl get pods -n kube-system –field-selector=status.phase!=Running

  • No impact (local cluster):
    > wipe the test namespace on my kind cluster
    kubectl –context kind-dev delete ns test

  • No impact (dry run):
    > kubectl apply –dry-run=server -f deploy.yaml
    (Dry run is treated as a read and allowed directly)

Scope and Caveats

  • Coverage: Currently only kubectl is supported; helm, argocd, and flux are not covered.
  • Runtime behavior: The plugin runs with the permissions of the current DSH process. You should review the source code and license yourself.
  • Limitations: It works by parsing command strings. If an Agent hides the binary name using environment variables, aliases, or base64 encoding, the plugin can be bypassed. It is intended to guard against a “confused Agent,” not to defend against a “malicious Agent.”
  • Security recommendation: If a stronger security sandbox is required, remove credentials instead of relying solely on command filtering.

Short Summary

dsh-kubectl-guard is a practical safety backstop, suitable for scenarios that need additional constraints on kubectl operations without modifying the core Agent code. See the GitHub repository for more details.