K8sGPT

The CLI uses whatever Kubernetes credentials are in the operator's kubeconfig (in-cluster service account first, otherwise the current context), so it typically runs with cluster-admin-level authority and never narrows it. What limits the damage is the design: every Kubernetes request is a hard-coded list or get call in the analyzers, the model never sees or uses the credentials, and nothing on the analyze path writes to the cluster. A hijacked model therefore cannot use the identity at all, but k8sgpt itself still reads cluster-wide with the full credential, including Secret objects it fetches to check that they exist.

In the scored CLI flow the model only returns text. It has no tools, and k8sgpt never acts on what the model says: the answer is stored in a local cache and printed. All Kubernetes calls on this path are read-only, so no consequential action exists that would need approval. The MCP server mode (not scored) is different: an MCP host can call a config tool that persists new custom-analyzer endpoints and remote cache buckets with no confirmation step.

The model is given no tools, so it never chooses arguments, paths, URLs or queries. Which analyzers run, the namespace and the label selector come from the operator's command-line flags, and the Kubernetes calls are fixed in code. Tool-argument scoping has no surface in the scored mode. The MCP server (not scored) does expose model-callable tools, and those include reading any Secret by name.

Nothing interprets model output or cluster content as code. The only process launch in the codebase opens a fixed OpenAI key-generation URL in the user's browser for `k8sgpt generate`. There is no shell tool, no eval, no template rendering of model text, and no plugin loading.

k8sgpt sends attacker-influenced cluster text to the model: event messages, container status messages and probe output that any workload owner can shape. The only in-prompt defence is a set of triple-dash delimiters. The pipeline is fixed in code before any of that text is read, and the model has no tools, so a hijacked model can only change the explanation the operator reads. The residual risk is the human: injected text can produce convincing but harmful remediation advice for an operator who usually holds cluster-admin, and model output is printed to the terminal without stripping control characters.

Configuration is read only from user scope: the XDG config directory, an explicit --config flag, or K8SGPT_* environment variables. Nothing is loaded from the working directory. The one persistent store the model influences is the response cache: each AI answer is written verbatim and served again, without calling the model, whenever the same failure text recurs. Entries carry no provenance and never expire. The default file cache is private to the OS user (mode 0600), but the cache key ignores which cluster or context produced it. A poisoned explanation can persist across sessions, though it only affects text shown to the operator. `k8sgpt cache purge` clears it.

Nothing third-party is enabled by default. There are two opt-in extension paths. The first is custom analyzers: remote gRPC services the operator registers and enables with the -z flag. They receive an empty request and no credentials, but the connection is unauthenticated plaintext and nothing pins or verifies the endpoint. The second is `integration activate keda`, which installs a version-pinned KEDA Helm chart from the official repository using the operator's kubeconfig, with no digest or signature check. The repository and version can be overridden through environment variables. A malicious chart would run in the cluster with whatever RBAC it declares.

The AI provider key is written in plaintext to the user's k8sgpt.yaml through viper. No file mode is set, so viper's default world-readable 0644 likely applies (inferred from the library default, not verified). `k8sgpt dump` masks the key and `auth list` never prints it. There is no telemetry or crash reporting, verbose output prints only the base URL and model, and cached answers are stored 0600. Cluster object names and event text go to the provider unmasked unless the operator passes --anonymize, which is off by default and masks only identifiers.

The CLI keeps no record of what it did: which resources it read, what text it sent to the AI provider, or what came back. The only output is the report on stdout, plus cached answers stored under hashed keys. Debug lines appear only with --verbose and go to stdout. The serve mode, which is not scored, does log each gRPC request with structured zap fields.

There is no agent loop to run away. Each run makes one completion per detected problem, each OpenAI completion is capped at 2,048 tokens, and Kubernetes concurrency is capped at 100. No limit applies to the number of calls per run or their total cost, and AI and Kubernetes requests use a background context with no timeout. Ctrl-C ends the process, which stops in-flight requests, and nothing keeps running in the background.