Why KubeAgent doesn't ask for your kubeconfig

The fastest way to compromise a Kubernetes cluster is to hand someone a kubeconfig. The second-fastest is to install an in-cluster agent with cluster-admin and a ServiceAccount token that gets minted on every pod start and silently exfiltrated to a vendor’s control plane.

Most observability products ask you to do at least one of those things. KubeAgent doesn’t. Here’s the architecture, and why it’s a deliberate constraint rather than an oversight.

Where KubeAgent actually runs

KubeAgent is a Node.js CLI. You install it with npm install -g kubeagent and run it on a machine you control — your laptop, a jumpbox, a CI runner, or a tiny VM inside your VPC that already has kubectl access. The watch command opens a polling loop that calls kubectl (or the in-process equivalent via your existing kubeconfig) every 60 seconds. When something looks wrong, it fetches more context (get logs, describe, get events) through the same local client.

Cluster credentials never leave the machine they were already on. There is no in-cluster sidecar, no ServiceAccount, no ClusterRoleBinding, no token that gets rotated by a vendor.

What does leave your network

Two things, both outbound:

1. Diagnosis prompts to the KubeAgent API at api.kubeagent.net. These contain the cluster context KubeAgent has decided is relevant to the current incident — pod logs, event lists, the contents of your local knowledge base. The API proxies them to Anthropic (Claude) so we can meter token usage for billing. We do not log or store the bodies of these requests. The privacy policy spells out the exact data retention.
2. Notification payloads to your alert channel — Slack, Discord, Teams, Telegram, PagerDuty, or a custom webhook. These contain incident and recovery details, again outbound from your machine to a destination you control. Approval-required actions remain in the active terminal.

That’s it. There is no inbound path from KubeAgent’s infrastructure back into your cluster. If our SaaS disappeared tomorrow, the worst case is that the watch loop stops being able to call the diagnoser; the cluster itself is untouched and unreachable from our side.

Why this matters beyond a security checklist

The architecture is not just a privacy story — it’s the reason the install takes five minutes instead of a quarter:

• No platform engineer in the loop. You don’t need to file a ticket to provision a ServiceAccount or open a firewall rule. If kubectl get pods -A works from your shell, KubeAgent works from your shell.
• Multi-cluster is free. Each kubeagent watch -c <context> instance reads a different kubeconfig context. There’s no per-cluster install to repeat.
• Headless and air-gapped paths work. kubeagent login --device does the OAuth dance with a six-digit code on a separate device, so you can run the CLI on a jumpbox with no browser. The cluster API doesn’t need to reach the internet — only your KubeAgent process does.
• Your security team has less to review. “It runs kubectl and posts to two outbound HTTPS endpoints” is a much shorter conversation than reviewing an in-cluster operator’s RBAC surface.

The tradeoff we accept

The honest tradeoff is that KubeAgent only sees what its host can see. If you run it on a CI runner with read-only access to one namespace, that’s the only namespace it can monitor. If your laptop sleeps, the watch loop sleeps with it. For teams that need monitoring 24/7, the answer is to run kubeagent watch on a small always-on VM (or a dedicated kubeagent user on a jumpbox) — but the kubeconfig stays under your control either way.

If you want round-the-clock auto-remediation but don’t want a single laptop to be the SPOF, the pattern most of our users settle on is a kubeagent-watch systemd unit on a 1-vCPU box inside the same VPC as the cluster, talking to the internal API endpoint. Six lines of unit file and it’s done.

The bottom line

We built KubeAgent this way because we’ve been the on-call engineer who got a Sev-1 ticket about “the monitoring agent” the third-party vendor installed three years ago that nobody can find the original IaC for. That’s not a position we want to put our customers in.

If “no inbound cluster access, no stored credentials, no long-lived tokens” is a hard requirement for your team — your auditor’s checklist, your zero-trust posture, your SOC 2 — KubeAgent is built to clear it from day one. Start on the free plan, no card needed, and kubectl get pods is the only credential anyone’s going to ask you for.

Read the Kubernetes auto-remediation guide for the action boundary layered on top of this credential model, or compare the approach with K8sGPT.