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.