Kubernetes safety with AI: plan, approve, hard denies, and production discipline

The fastest way to hurt a Kubernetes cluster with AI is also the simplest: pipe model output straight to bash. One wrong namespace, one hallucinated resource name, one delete verb you didn't read — and your incident becomes a postmortem about automation, not about the original bug. Safety is not a feature checkbox for AI ops tools. It's the architecture.

kprompt treats every mutating prompt as untrusted until a human or an explicitly configured pipeline approves a structured plan. Read-only work (get, list, explain, logs, describe) runs immediately. Everything else hits Plan → Safety → Apply. This post explains that loop, what hard denies block, and the production habits that still matter when the CLI does the right thing.

Plan → Safety → Apply (the whole model)

Prompt in plain English. kprompt maps intent to concrete operations — usually kubectl commands with namespace and context resolved. Before exec, the tool evaluates risk: low, medium, high, or denied. On a TTY you confirm y/N unless you pass --approve. Denied plans never run, regardless of flags.

$ kprompt "scale api to 3" -n staging

Plan
  1. kubectl scale deployment/api --replicas=3 -n staging

Risk: low
Apply? [y/N]

That pause is the product. The LLM suggested intent; the plan shows exactly what touches the apiserver. You're not approving English — you're approving commands.

Hard denies: what never applies

Some prompts fail closed. Hard denies catch wipe-class language and operations outside named-resource delete rules. Models can be manipulated or confused; hard denies don't negotiate.

• Cluster or namespace wipe phrasing
• Delete-everything style requests
• Deleting an entire namespace
• Deletes that aren't a named Pod, Deployment, or Service

$ kprompt "delete all pods in production"

Risk: denied
# Plan does not apply — named resources only

Named delete still requires approval and shows up in the plan — you delete deployment redis, not everything in a namespace. That matches how careful operators already work; the CLI enforces it even when the prompt is reckless.

Risk levels and what they mean

• low — routine scale or rollout on scoped resources; still needs approval on a TTY
• medium — production namespaces, rollbacks, or wider blast radius
• high — operations that deserve extra scrutiny and slower approval
• denied — hard stop; fix the prompt or use supported delete patterns

Risk labels are signals, not substitutes for reading the plan. Medium in staging might be acceptable during a drill; medium in production might need a second pair of eyes — process kprompt doesn't replace.

Live diffs: review the change, not just the sentence

When the target object exists, plans can include before→after diffs — replica count changes, image tag updates, resource limit patches. That's critical for AI-assisted ops: the model's summary might sound right while the diff shows a wrong tag or limit. Train teams to look at diffs first on mutations that change spec.

When --approve is appropriate

--approve skips the interactive y/N prompt. Use it in CI after JSON gates, in scripts you've tested on staging, or in replay from kprompt history when the plan is unchanged. Do not use it as default on production laptops because it's convenient.

• OK — staging automation with jq gates on PlanResult JSON
• OK — history rerun of a plan you already reviewed interactively
• OK — local kind clusters while learning the tool
• Risky — first time running an unfamiliar prompt in prod
• Risky — combining --approve with loose CI checks

kprompt "rollback api" -n staging --approve --wait --timeout 10m

Safety vs RBAC vs admission control

kprompt safety is not a replacement for Kubernetes RBAC, OPA/Gatekeeper, or Kyverno. It's a pre-execution layer on the operator's machine. RBAC limits what credentials can do; admission hooks enforce org policy at the apiserver; kprompt limits what gets suggested and executed from natural language before it reaches either. Stack all three for production.

Three demo scenarios that show the model

1. Plan + approve scale

The bread-and-butter demo: scale a Deployment, read the kubectl line, accept or reject. For recordings without apply, use JSON output and jq to show intent and risk without touching the cluster.

kprompt --output json "scale api to 3" -n staging | \
  jq '{intent:.plan.intent, risk:.risk.level, denied:.risk.denied}'

2. Explain before mutate

Incident flow: explain why a workload is crashing (read path, no approval), understand OOM or probe failure, then consider a bounded fix — memory patch or rollback — with a fresh plan and approval. AI accelerates diagnosis; humans still own the fix.

kprompt "explain why api is crashing" -n staging
# ... read output ...
kprompt "rollback api" -n staging   # separate plan + approve

3. Safety denial

Show that wipe language fails closed. Stakeholders need to see denial as success — the tool refused an unsafe class of operation, not a model error.

Experimental software — stay honest

kprompt is early-stage MIT CLI. Safety rules reduce risk; they do not certify production readiness. Plans can be wrong within allowed operations — wrong deployment name, wrong replica count, wrong namespace if flags are ambiguous. Hard denies don't catch every mistake. Start on kind or non-production; keep --approve off until plans feel familiar.

Production checklist

• Set default namespace and context in config — reduce ambiguous prompts
• Read the plan and diff on every mutation in shared clusters
• Use -n and --context explicitly for production commands
• Prefer JSON plan artifacts in CI before any automated apply
• Rotate LLM keys separately from kube credentials; neither belongs in config.yaml
• Disable local history on shared jump hosts if prompts are sensitive

Try the safety loop

curl -fsSL https://kprompt.ai/install | bash
export KPROMPT_GEMINI_API_KEY="..."

kprompt "delete all pods" -n staging    # expect deny
kprompt "scale api to 2" -n staging    # review plan → y or n

Full safety reference: kprompt.ai/docs/safety. For CI gating, see our post on PlanResult JSON. The goal is simple: AI speed with operator control — not autopilot with a Kubernetes sticker.