kubectl-ai

kubectl-ai runs every command with whatever credentials your kubeconfig holds, plus your entire shell environment, and never narrows them. There is no authorization layer between the model's requests and the cluster: the only control is the approval prompt scored under approval gates. An opt-in Kubernetes sandbox runs commands in a pod under a dedicated read-only service account defined in the shipped RBAC manifests, which is a real narrowing, but it is off by default and MCP servers still run on the host with full authority.

A deterministic classifier decides which commands need your approval: anything it cannot prove to be a single read-only kubectl call is shown to you in full before it runs, including all bash, custom-tool and MCP calls, and compound shell commands are parsed rather than prefix-matched. The gap is the read-only allowlist itself, which is not a strict boundary. Every prompt also offers a session-wide 'don't ask me again'.

Both built-in tools take a free-form string and run it with bash -c, so the 'kubectl' tool is in practice a second shell tool. The only input checks block 'kubectl edit' and 'kubectl port-forward' substrings, to avoid interactive hangs rather than as a safety boundary. Nothing bounds namespaces, resources, paths or hosts, and the bash and kubectl tools are always enabled.

By default every model command runs directly on your machine through bash, as your user, with your full environment and kubeconfig. The 'seatbelt' option on macOS is not a complete boundary. The opt-in Kubernetes sandbox runs commands in a stock pod (bitnami/kubectl:latest, no security context), which is basic container separation, but it exports the host's entire environment, including LLM API keys, into each command, and MCP servers still run on the host.

kubectl-ai reads cluster content that any workload owner can control (pod logs, events, annotations, configmaps) and feeds it back to the model as ordinary tool results. Nothing tracks that content as untrusted. The approval gate does stop most shell egress and kubectl writes, and compound commands are deliberately sent for approval to block exfiltration. But a hijacked agent can still read secrets with an auto-approved 'kubectl get secret', and the gate does not cover every path, so it can exfiltrate data and delete resources without a prompt.

kubectl-ai loads no instruction files from the project you run it in, and by default conversations live only in memory. Its settings come from ~/.config/kubectl-ai (config.yaml, tools.yaml, mcp.yaml), which looks like safe user scope, but the approval gate does not cover every path, so the agent can write those files itself, and a written config can turn off approvals, register custom tools or enable MCP servers for every later session.

No third-party extension runs in the default configuration, but the extension mechanism is weak when enabled. The '--mcp-client' flag auto-creates a config that launches an unpinned 'npx -y' MCP server, with no hashes or re-approval. The first-run configuration handling is not locked down. MCP servers launch as the same user via the mcp-go library, inferred to inherit the full environment.

API keys come from environment variables, and nothing in kubectl-ai redacts anything. Tracing is on by default and does not protect sensitive data. Every subprocess also receives the full environment.

Every tool call, including custom and MCP tools, is written to a structured YAML trace with its arguments, result and timestamp, and this is on by default. The record has gaps: it does not log approvals or denials, it does not say who asked or who approved, it is overwritten on every launch, and its storage location is not locked down. Write errors are ignored.

The agent stops after 20 model iterations per request, but there is no wall-clock limit, token budget or cost cap, and individual commands have no timeout except a 7-second cap for watch, follow-logs and attach. Ctrl+C cancels the context, which kills the bash child process but not any process group or background jobs it started. Long-running commands can run indefinitely.