Answer
Can an AI coding agent use my kubeconfig / access my Kubernetes cluster?
Yes, if the agent can run shell commands. ~/.kube/config lists contexts — cluster endpoints bundled with user credentials, which may be an embedded bearer token, a client certificate and key, or an exec plugin that fetches short-lived credentials from your cloud provider. An agent running kubectl as you inherits whatever that active context can do. Scope contexts narrowly with RBAC, or hand agents a separate, limited kubeconfig.
Updated · Kloudle
What's actually inside a kubeconfig file?
According to the Kubernetes documentation, a kubeconfig file organizes clusters (server address and certificate authority), users (authentication credentials), and contexts, which group a cluster, a user, and a namespace under one name so kubectl can switch between them. By default kubectl reads $HOME/.kube/config, or whatever KUBECONFIG points to.
The user entry's credentials can take a few forms: an embedded client certificate and key, an embedded bearer token, a username and password, or an exec block that runs an external command (for example a cloud CLI) to fetch a token on demand.
Can an agent run kubectl with my permissions?
Yes. An AI coding agent that can execute shell commands runs as your user, and kubectl picks up your default kubeconfig the same way it would if you typed the command yourself. There is no extra prompt or separate credential step — whatever your current context is authorized to do against the cluster, a command the agent runs can do too.
What's the difference between embedded credentials and exec plugins?
An embedded token or client certificate sits in the kubeconfig file as plain text (or base64), so anyone who can read the file can read the credential directly, and it is often long-lived until manually rotated.
An exec-based plugin — common with managed cloud clusters — instead runs a command each time kubectl needs credentials, typically producing a short-lived token from your already-authenticated cloud CLI session. The file itself doesn't hold a long-lived secret, but that only changes what's visible by reading the file; an agent that can execute kubectl still triggers the plugin and gets a working credential in the process.
How do I limit the blast radius with RBAC and separate kubeconfigs?
Kubernetes RBAC lets you grant exactly the permissions a workflow needs and nothing more. A namespaced Role plus a RoleBinding (or a cluster-scoped ClusterRole and ClusterRoleBinding) defines a set of allowed verbs on specific resources; per the Kubernetes documentation, RBAC permissions are purely additive, so a tightly scoped Role has no way to accidentally gain more access than it was granted.
Create a dedicated service account and Role scoped to what an agent actually needs (for example, read-only access to one namespace), bind it with a RoleBinding, and generate a separate kubeconfig for that identity instead of pointing agents at your full-access, multi-cluster config. Prefer short-lived, exec-sourced tokens over long-lived embedded ones where your cluster supports it.
What does Agent Blast Radius report about my kubeconfig?
The scan reads ~/.kube/config and reports the contexts and users it defines, along with any embedded token or key material it finds in the file. It never runs an exec auth plugin itself — it does not shell out to your cloud CLI or fetch a live token on your behalf. The report describes what the file currently exposes, not what any particular context can do once kubectl actually connects to the cluster.
Check your own machine
See what an agent running as you can reach. Offline, read-only, never prints values:
npx -y @kloudle/agent-blast-radius@0.3.0Inside your agent: install guides for Claude Code, Codex, Cursor, Claude Desktop and more. Which keys are live? npx -y @kloudle/agent-blast-radius@0.3.0 verify (paid per check).
Frequently asked
Does Agent Blast Radius run my exec plugin (aws eks get-token, gcloud, etc.)?
No. It reads the kubeconfig file's structure and reports embedded token or certificate material, but it never executes an exec-based credential plugin.
If my kubeconfig uses an exec plugin instead of a stored token, am I safe from agent access?
Not fully. The agent can still invoke kubectl, which triggers that plugin using your cloud CLI's own session. Whether the file holds a token directly or calls a plugin changes what's visible by reading the file, not what kubectl can ultimately do once run.
How do I give an agent reduced Kubernetes access?
Create a dedicated context bound to a narrowly scoped RBAC Role or ClusterRole, save it as a separate kubeconfig file, and point only trusted tools at your full-access context.
Does removing ~/.kube/config stop an agent from reaching my cluster?
It removes the easiest path, but if kubectl is configured via the KUBECONFIG environment variable, another file path, or the agent can reach the Kubernetes API directly with credentials found elsewhere, removal alone doesn't guarantee isolation.
Sources
- Organizing Cluster Access Using kubeconfig Files — Kubernetes documentation
- Using RBAC Authorization — Kubernetes documentation