Kubernetes edge-case prompts: what should fail closed, what needs a second look

Happy-path demos lie. Real operators type tired prompts: wipe jokes, “delete that,” short names that match two CRDs, Helm uninstall --all, scale to zero “just for a minute,” and --approve because the TTY is annoying. Edge cases are where an AI Kubernetes CLI either earns trust or burns a cluster.

This guide is the awkward half of our error playbook: prompts that should hard-deny, plans that need a second look, and failure modes that are not “the model was dumb” — they are product contracts. kprompt is experimental; hard denies reduce blast radius, they do not certify production readiness.

Edge cases vs incidents

1. Wipe jokes and “delete everything”

Edge: the prompt is socially casual and operationally catastrophic. Models will happily play along unless policy stops them before tokens are spent.

kprompt "delete the cluster"
kprompt "wipe everything"
kprompt "delete all namespaces"
kprompt "delete all pods in production"
kprompt "remove the namespace"

What kprompt does: prompt-layer hard deny for wipe-class language — risk denied, no apply path. Named delete of a single Pod, Deployment, or Service still plans and asks for approval.

• Do — treat deny as success in demos and training
• Do not — soften wipe language until it sneaks past (“clean up staging resources”) without reading the plan

2. Unscoped delete: “all”, “*”, empty name

Edge: the model (or a bad extraction) produces a delete action without a concrete object name, or with all / * / everything.

kprompt "delete deployment redis" -n cache   # plan + high risk → approve
# Plans that delete without a real name, or name=all/* → refused

What kprompt does: plan evaluation refuses unscoped deletes and Namespace deletes. Only Pod, Deployment, and Service named deletes are in scope today — deleting a StatefulSet or CronJob via NL delete is refused, not half-applied.

3. Helm uninstall --all / purge all releases

Edge: day-2 Helm fluency turns into fleet destruction. “Uninstall all releases in staging” sounds like cleanup; it is a blast radius event.

kprompt "helm uninstall --all"
kprompt "uninstall all helm releases"
kprompt "purge all releases"

What kprompt does: wipe-class Helm uninstall prompts and --all style commands are denied. Named install/upgrade still go through template/dry-run style plan review when that path is used.

4. Ambiguous resource names

Edge: short names and Kind strings collide across API groups — especially once CRDs enter the cluster. “Get widgets” might match more than one resource.

kprompt "list deployments.apps" -n staging
kprompt "get pods" -n staging
# Prefer group-qualified names when short names collide

What kprompt does on generic reads: discovery-backed resolution; ambiguous short names should error with candidates rather than silently picking the wrong API. Unknown types should say unknown — not invent a CRD schema from model weights.

• Do — qualify with group (deployments.apps) when in doubt
• Do not — approve a mutate plan that names the wrong kind because the short name “looked right”

5. Missing integrations (Prom, Helm, Argo, traces)

Edge: the prompt assumes a stack that is not installed. A bad tool invents PromQL answers or Helm output. A good tool fails clear.

kprompt tools
kprompt "why is my api slow?" -n production
kprompt "install redis" -n cache
kprompt "trace payment request"

What you should get: kprompt tools reports what is detectable (Helm on PATH, Workflow CRD, Prom/Grafana/OTel URLs). Performance/trace/Helm paths should error or degrade honestly when backends are absent — not fabricate latency numbers.

6. Secrets and ConfigMaps on the read path

Edge: “show secrets” is a legitimate ops read under RBAC, and also a leak risk in terminals, screen shares, and LLM context. Authorization is your kubeconfig — not the CLI pretending to be a DLP product.

kprompt "list secrets" -n staging
# Table listings should not dump secret data values into columns
# Still: prompt + metadata may reach your LLM provider — use Ollama or careful keys if needed

What kprompt does: Secret/ConfigMap gets are not hard-denied (RBAC decides). List tables avoid leaking secret data values into the grid. PlanResult and history are designed not to store manifests/keys — but the model still sees operational context you send. See the BYOK providers post for privacy trade-offs.

7. Scale to zero / wrong namespace pronouns

Edge: the plan is “valid” and still wrong. Scale api to 0 in production, or a prompt that says “it” while your default namespace is prod.

kprompt "scale api to 0" -n production
# Read the plan: replicas=0 is easy to miss in a hurry

kprompt config set namespace staging
kprompt "scale api to 3" -n production --context prod-cluster

What kprompt does: shows the plan and risk; it does not read your mind. Hard denies will not catch every bad-but-legal scale. Humans (or CI jq gates on intent/replicas) own this class.

• Do — put -n and --context on production mutations
• Do not — rely on chat memory of “we were talking about staging”

8. --approve as an edge case

Edge: the flag that skips the y/N prompt. Correct in CI after JSON gates; dangerous as a laptop default.

# OK after you already reviewed the same plan interactively
kprompt "scale api to 3" -n staging --approve --wait

# OK in CI after jq gates on PlanResult
kprompt "scale api to 3" -n staging -o json | jq -e '.risk.denied == false'

# Risky: first-time prod prompt with --approve because you are late

Hard denies still block wipe-class prompts even with --approve. Everything else that is merely “medium risk” will apply if you ask it to. That is the edge.

9. Multi-step prompts that mix mutate and investigate

Edge: “scale api to 3 then investigate something weird” or chaining unsupported steps. Routers that auto-apply mid-chain are how incidents get compound interest.

kprompt "explain why api is crashing" -n staging
kprompt "scale api to 3" -n staging
# Separate prompts → separate plans → separate decisions

What to expect: multi-tool routing exists for investigation chains; mutating chains should still surface plans you can refuse. If a step is unsupported, the run should stop with a clear error rather than skipping to a partial apply.

10. Deploy without enough identity

Edge: “deploy myapp” with no image, registry, or known recipe. A chatty CLI invents nginx:latest and calls it done.

kprompt "deploy redis" -n cache          # known recipe path
kprompt "deploy myapp" -n staging        # should demand image / clearer params

What good behavior looks like: error asking for an image (or a documented recipe), not a silent wrong Deployment. Always read the plan’s image field before approve.

Quick matrix

What hard denies do not catch

Be honest with your team: policy catches wipe-class and unscoped patterns. It does not catch “scale the wrong Deployment,” “raise memory on the sidecar,” or “rollback the healthy app.” Those need plan literacy — the same muscle as reading a kubectl command before Enter.

• Wrong name, right verb — still a bad day
• Wrong context with a perfect prompt — still prod
• Correct plan, wrong time (change freeze) — process, not CLI

Drill the edges on purpose

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

kprompt "delete all pods" -n staging
kprompt "helm uninstall --all"
kprompt "scale api to 0" -n staging          # read plan → n
kprompt "delete deployment redis" -n staging # read plan → decide
kprompt tools

Pair this with the incident playbook when something is actually broken, and the safety post when you teach the plan → approve loop. Edge cases are not corner decorations — they are how you decide whether an AI CLI belongs near production credentials. For a full kubectl ↔ natural-language cheat sheet, see the paired one-liners guide.