Welcome to the NZRT Wiki Podcast. Today we’re looking at kagent-claude.

kagent-claude is a setup that gets kagent version 0.8.6 running on Windows 11 using Minikube, with Claude Sonnet as the AI model powering it. The session was saved back in April 2026 and at that point it was running fine, just waiting on an API credit top-up.

Let’s start with the environment. You’ve got six tools in play here. Minikube at version 1.38.1, kubectl at version 1.34.1, Helm at version 4.1.4, Docker Desktop at version 29.4.0, kagent itself at version 0.8.6, and the Claude model being used is claude-sonnet-4-6. Minikube is using Docker as its driver, running through WSL2. Memory is capped at around 3,800 megabytes, which is the Docker Desktop limit. Everything lives in a Kubernetes namespace called kagent.

Now let’s walk through the three Kubernetes resources that were created to make this work.

The first is a secret. This is how you securely pass your Anthropic API key into the cluster. The command creates a generic secret called kagent-secrets inside the kagent namespace and stores your API key under a label called ANTHROPIC_API_KEY. Think of it as a locked box that Kubernetes can open whenever it needs to authenticate with Anthropic.

The second resource is a ModelConfig, called claude-sonnet. This is essentially a configuration file that tells kagent which AI model to use and how to use it. It points to Anthropic as the provider, specifies claude-sonnet-4-6 as the model, and references that secret you just created so it can grab the API key. There is also a field for the secret key name pointing to ANTHROPIC_API_KEY, and this is important — we will come back to why in a moment. The model is configured with a maximum of 8,096 tokens and a temperature of 0.7, which gives you a balance between creative and focused responses.

The third resource is the agent itself, called claude-test-agent. This is a declarative agent using the Python runtime, pointed at your claude-sonnet model config. Its system message tells it to act as a helpful Kubernetes assistant powered by Claude Sonnet. It is also wired up to four Kubernetes tools via an MCP server: one for getting resources, one for describing a resource, one for fetching pod logs, and one for retrieving cluster events. So this agent can actually look around your Kubernetes cluster and answer questions about what is happening inside it.

Once everything is deployed, you access the UI through a port-forward command. This routes the kagent UI service from inside your cluster out to port 8080 on your local machine, so you can open a browser and go to localhost colon 8080 to start chatting with your agent.

If you ever need to resume the setup after a restart, the process has four steps. Start Docker Desktop, then run minikube start with the Docker driver, then run the port-forward command again, and finally open localhost colon 8080 in your browser.

Now, there are three known issues worth knowing about.

The first is an authentication error that says something like could not resolve authentication method. This happened because the ModelConfig was originally written with the wrong field name — the incorrect version ends in Ref, but the correct field name does not. The fix is to recreate the ModelConfig with the right field name, then bounce the agent by scaling its deployment down to zero replicas and back up to one.

The second issue is pods getting stuck in a pending state due to not enough memory. With only around 3,800 megabytes available, too many bundled agents were competing for resources. The fix was deleting the agents that were not needed — specifically the Cilium debug, manager, and policy agents, the kgateway agent, and the argo-rollouts conversion agent. Removing those freed up enough memory for everything important to run.

The third issue is a 400 error related to API credits. This is a billing distinction that is easy to miss: your Claude Pro subscription on claude.ai and your Anthropic API account at console.anthropic.com are completely separate billing systems. If you are using kagent with an API key, you need credits in the API console specifically. The fix is to top up at console.anthropic.com under settings and then billing.

So to recap: kagent-claude gives you a Claude-powered Kubernetes assistant running locally in Minikube. You set it up with a secret for your API key, a ModelConfig pointing at Claude Sonnet, and a declarative agent with four Kubernetes tools attached. The UI is a simple port-forward away. Watch out for the field name on the ModelConfig, keep memory free by pruning unused agents, and make sure your API credits are topped up separately from your Claude subscription.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

Welcome to the NZRT Wiki Podcast. Today we’re looking at Kagent Overview.

So, what exactly is Kagent? At its core, Kagent is a Kubernetes-native AI agent framework. It was contributed to the Cloud Native Computing Foundation — the CNCF — by Solo.io, and it made its debut at KubeCon EU in 2025. The idea is straightforward but powerful: you define AI agents in YAML, deploy them as Kubernetes workloads, and those agents use a large language model — like Claude or one of several other options — to automate cluster operations, troubleshoot issues, and handle DevOps workflows directly inside your cluster.

What makes this interesting is that your agents aren’t some external service bolted onto your cluster. They run as standard Kubernetes Pods. That means they’re fully observable, they can be restarted, they can be scaled, and they fit right into your existing operational patterns. You get multi-LLM provider support out of the box — Anthropic, OpenAI, Azure OpenAI, Google Vertex AI, and even Ollama for local models. You also get a built-in tool ecosystem using the MCP protocol for Kubernetes operations, plus a web UI, a command-line tool called kagent, and of course the YAML-based interface you’d expect in any Kubernetes-native project.

Now let’s talk about how the architecture hangs together. Picture your Kubernetes cluster with four main moving parts working in concert.

First, you have the Controller. This is a Go deployment that sits and watches for changes to the custom resource definitions — the CRDs — that Kagent introduces. When you create or update an agent definition, the Controller is what responds and creates the underlying Pods and Services.

Second, there’s the ModelConfig. This is a CRD that defines your LLM provider — so, say, Anthropic — along with the specific model name you want to use and a reference to a Kubernetes Secret that holds your API key. This keeps your credentials managed the Kubernetes way, which is exactly what you’d want.

Third, you have the MCPServer CRD. This is what exposes the tools your agent can actually call. Think of things like kubectl operations, Helm chart management, Argo workflows, and so on. These tools follow the MCP protocol, and they’re what give your agent its ability to actually do things in the cluster rather than just talk about them.

And fourth, bringing it all together, you have the Agent CRD itself. This combines your ModelConfig, your MCPServer tool definitions, and a system prompt into a single running Pod. That’s your agent — live, running, ready to take requests.

So how does it actually work when you send a message? The flow goes like this. You send a message to the agent — through the web UI, the CLI, or the API. The agent takes your message along with its configured system prompt and sends it to Claude, or whichever LLM you’ve set up. Claude then looks at the available tools from the MCPServer and picks the right ones to use. Those tools execute against the Kubernetes API — so actions like getting pod status, reading logs, applying a manifest, or checking service connectivity happen in your actual cluster. Claude then takes those results, synthesises them, and sends back a coherent response. And throughout all of this, every action is traced via OpenTelemetry, so you have full observability into what your agent did and why.

Now, thinking about how NZRT would actually use this — there are four key patterns worth knowing about.

The first is an SRE troubleshooter agent. This is a read-only diagnostics setup, using tools to get resources, read pod logs, pull events, and describe resources. Safe, observational, great for first-line investigation.

The second is a deployment helper. This one steps it up a notch — it can generate manifests and apply them, patch resources, and check service connectivity. Your agent becomes an active participant in your deployment process.

The third is a Helm operator. Using the Helm MCP server, your agent can manage charts — installing, upgrading, rolling back — all driven by natural language instructions.

And the fourth is a monitoring analyst. Hook your agent up to the Prometheus MCP server and it can run metrics queries, surface anomalies, and give you plain-language summaries of what your cluster is doing.

If you want to go deeper from here, there are a few related wiki pages to check out. Kagent Setup covers the step-by-step install and configuration for NZRT specifically. Kagent RBAC and Security goes into service accounts, roles, and how to restrict what tools an agent is allowed to use — important for any production setup. And Kagent Agents and Tools gives you the full MCP tool reference along with example agent CRD definitions you can adapt.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

Welcome to the NZRT Wiki Podcast. Today we’re looking at Kagent RBAC & Security.

This episode covers the security model for kagent running in the NZRT Kubernetes cluster. We’re talking about ServiceAccounts, role-based access control, API key management, tool restrictions, and network isolation. Let’s get into it.

The foundation of everything here is the principle of least privilege. That means each agent gets only the permissions and tools it actually needs — nothing more. At NZRT we run two agent classes. The first is the read-only class, used for SRE diagnostics. These agents can get, list, and watch any resource in the cluster, and they have access to tools like fetching resources, reading pod logs, describing resources, checking events, and testing service connectivity. The second class is the write agent, used for deployment and operations work. It has all the same read permissions, plus the ability to create and patch Deployments and Services. One thing that’s true for both classes — the destructive delete tool is never included. Full stop.

Now, each agent runs under its own dedicated ServiceAccount. The YAML definition for this is straightforward — you’re creating a ServiceAccount in the kagent namespace, giving it a name like kagent-sre, and labelling it with the NZRT owner and service code. One ServiceAccount per agent keeps permissions clean and auditable.

For the read-only SRE agent, you create a ClusterRole that grants get, list, and watch verbs across a broad set of resource types — pods, pod logs, deployments, replica sets, stateful sets, services, endpoints, events, namespaces, config maps, ingresses, jobs, and cron jobs. That ClusterRole then gets bound to the ServiceAccount via a ClusterRoleBinding. So the role defines what’s allowed, and the binding connects that role to the specific agent identity.

The write agent works a bit differently. Instead of a ClusterRole that applies everywhere, it uses a namespaced Role — scoped specifically to the staging namespace, not production. That Role allows get, list, watch, patch, and update on Deployments, and get, list, watch, create, and patch on ConfigMaps and Services. If you ever need production write access, the wiki is clear: that requires an explicit review before it gets granted. No shortcuts there.

Let’s talk API key security, because this one matters a lot. There are four rules NZRT follows. First, API keys never go in a ConfigMap — they live in a Kubernetes Secret only. Second, they never go in Git — you create them directly using the kubectl command or an external secrets operator. Third, the Anthropic key is namespace-scoped, meaning it lives only in the kagent namespace. And fourth, rotation is handled by updating the secret value, and any pod that restarts will automatically pick up the new key. The rotation command shown in the wiki takes the new key value and applies it using a dry-run pipeline to update the existing secret in place — clean and non-destructive.

Tool restriction is next. Each agent has an explicit whitelist of tool names. If a tool name isn’t on the list, the agent simply can’t use it. For a read-only agent, the whitelist includes things like listing API resources, reading pod logs, describing resources, and fetching cluster events. Tools like applying manifests are commented out with a note that they’re not included for read-only agents. And the delete resource tool? Also commented out, with a note that it’s never included. The guidance here is to start with the minimum set and only add tools when you have a specific, justified use case.

Network isolation is the last infrastructure control. A NetworkPolicy restricts what the kagent pod can reach on egress. It allows outbound TCP on port 443 to the Kubernetes API server — using the specific IP range for your cluster — and outbound TCP on port 443 to reach the Anthropic API. That’s it. The pod can’t freely reach the internet or other internal services.

Finally, every agent’s system prompt should include a set of safety instructions. These are written in plain language: always use informational tools before any modification tools, never delete resources, never expose Secret values in responses, and for any destructive or risky action, output the command but wait for human confirmation before proceeding. These rules act as a last line of defence at the model level.

Put it all together and you’ve got defence in depth — ServiceAccounts isolate identity, RBAC limits what each identity can do, Secrets protect credentials, tool whitelists constrain agent behaviour, network policies limit egress, and system prompt rules guide the model itself.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.