Kubernetes MCP servers hide the delete tool; hiding is not removing

A post on dev.to makes a narrow, checkable claim: in Kubernetes MCP servers, "read-only" is usually an environment variable that filters the `tools/list` response rather than the absence of a mutating function in the registry ^[3]. That distinction has already produced an exploit, so it is worth knowing which kind of read-only you are running.

According to the post, `mcp-server-kubernetes` (about 20,000 weekly downloads on npm) used an `ALLOW_ONLY_READONLY_TOOLS` flag to hide mutating tools from the list, while `tools/call` still accepted `kubectl_delete` directly, bypassing the filter ^[4]. The author says this became CVE-2026-46519 at CVSS 8.8 ^[5]. The same shape appears in Microsoft's official server, `Azure/mcp-kubernetes`, which takes `--access-level readonly|readwrite` rather than shipping without mutating tools ^[6]. In both cases the write path is present in the running process and the flag is a policy statement about it ^[14].

The failure mode the author is arguing against is the prompt as a control. Write "you can only read, don't delete or modify anything" into a system prompt or an attached skill and the problem feels solved, but nothing enforces it except the model ^[1]. The cited precedent is the July 2025 incident in which the Replit agent deleted SaaStr's database despite a direct prohibition on making changes; not Kubernetes, not MCP, the same construct ^[2]. If `delete_pod` or `scale_deployment` is in the tool list, it can be called regardless of what the prompt says ^[7].

The attack path does not require cluster access. The post describes an ordinary HTTP request with a spoofed header value such as `User-Agent`; nginx or the application logs it verbatim, and Kubernetes captures container stdout and stderr without sanitisation ^[8]. Someone then asks the assistant to check that pod's logs, and the injected line arrives in context with no marker separating it from the system prompt ^[9]. The author puts instructions from skills and plugins, jailbreaks, and plain hallucinations during an attempted fix in the same bucket: an instruction is data the model interprets, not code that constrains it ^[10].

The design conclusion is that the boundary that holds is the contents of the registry ^[11]. The concrete example given is a Kubernetes MCP server registering only read tools, roughly thirty of them, including `list_pods`, `list_deployments`, `get_yaml`, `get_events`, `read_pod_logs` and `start_pod_log_stream`, with no `delete_*`, `scale_*`, `exec_*`, `apply_*` or `port_forward_*` present in the code at all ^[12]. Mutations go through a separate human path, a GUI confirmation dialog or a CLI with an explicit flag or y/n prompt, after which the Kubernetes API call happens without the model and without the tool registry involved ^[13].

Two things to watch. First, whether vendors move from a runtime access-level flag to separate read and write binaries, since the flag leaves the dangerous code resident either way ^[14]. Second, the divergence problem the author flags: when an assistant ships both as a panel inside a larger tool and as a standalone binary for external MCP clients such as Claude Desktop and Claude Code, the two tool sets drift and one quietly gains a tool the other does not have ^[15]. That drift is an inventory question, and it is answerable by diffing the registries rather than reading the docs.