DEV Community: r

Read-only by construction: why instructions aren't a security boundary for an AI agent in a Kubernetes cluster

Sat, 22 Aug 2026 07:03:17 +0000

I keep running into the same setup: take an LLM, give it access to kubectl or the k8s API, write something like "you can only read, never delete or change anything" into the system prompt or a connected skill, and consider the problem solved. I've been through this myself, and at some point I realized: that's not a security boundary, it's a polite request.

This isn't a hypothetical risk: you've probably heard the story — in July 2025, a Replit agent deleted SaaStr's production database despite an explicit instruction not to touch anything. Not Kubernetes, not MCP, but the same pattern: the instruction "don't touch this" was right there in context — there was just nobody to enforce it except the model itself. Giving an agent write access to a k8s cluster means assembling exactly the same setup that already cost SaaStr their database.

I'm far from the first to write about this, and plenty of read-only MCP servers have shown up recently. What's surprising is how often "read-only" gets implemented wrong. For Kubernetes MCP servers specifically, "read-only" is often just an environment variable that filters the tools/list response, not the absence of a function in the registry. That's exactly how mcp-server-kubernetes (20K weekly npm downloads) was built: the ALLOW_ONLY_READONLY_TOOLS flag hid mutating tools from the list, but tools/call still accepted kubectl_delete directly, bypassing the filter. The result was CVE-2026-46519, CVSS 8.8 — the exact principle this article is about, taken all the way to a real exploit: a function hidden from the list isn't the same as a function that doesn't exist. And it's not just community projects — Azure/mcp-kubernetes, Microsoft's own official Kubernetes MCP server, is built the same way: --access-level readonly|readwrite instead of the absence of mutating tools in the first place.

Why instructions don't work as a boundary

A model is not a sandbox. If delete_pod or scale_deployment is in its list of available tools, it can technically call it regardless of what the system prompt says. For example, an attacker doesn't need cluster access for this — an ordinary HTTP request with a spoofed header value like User-Agent is enough. Nginx, or the pod itself, will log it verbatim: Kubernetes just captures the container's stdout/stderr, with no sanitization at all. Later, someone (or the assistant itself) asks the model to "check this pod's logs" — a completely innocent request — and the model reads that line as part of its context, with no way to tell it apart from the system prompt. Same story with an instruction from a connected skill or another plugin, which ends up in context just as "trusted"; with a jailbreak; with an ordinary hallucination while trying to "fix" a problem you only asked it to explain. An instruction — whether in the system prompt, in a skill, or in a container log — is data the model interprets, not code that constrains it.

So the only boundary that actually holds is which tools exist at all in the registry it has access to. If the delete_pod function doesn't exist, it doesn't matter what a prompt injection, a jailbreak, or the model itself in a fit of "helpfulness" says — there's nothing to call.

What this looks like in the tool registry

Take a concrete example: an MCP server for Kubernetes. It makes sense to register only read tools in it — list_pods, list_deployments, get_yaml, get_events, read_pod_logs, start_pod_log_stream, and so on, on the order of thirty of them. And not a single delete_*, scale_*, exec_*, apply_*, or port_forward_* — not because they're switched off by some flag, but because those functions simply don't exist in the code.

All mutating operations — scale, rollout restart, delete, cordon/drain — live on a separate, human-only path in a design like this: through a GUI with a confirmation dialog, through a CLI with an explicit flag or a y/n prompt, doesn't matter which — what matters is that a human confirms it, and only then does a direct call to the Kubernetes API happen, with no model and no AI tool registry involved at all. These are two separate code paths, not one gated by an allowed/forbidden flag.

One server, two transports

A separate problem shows up when an AI assistant is available in two forms: as an embedded panel inside a larger tool, and as a standalone binary for external MCP clients (Claude Desktop, Claude Code, etc.). The temptation is to throw together a separate tool set for the embedded version. Over time the two sets drift apart, and one ends up with an extra tool the other doesn't have.

More reliable: bring up the same MCP server in both cases and talk to it for real over the MCP protocol, just over different transports — in-memory for the embedded version, stdio for the external client:

server, shutdown := mcpserver.NewServer(ctx)
serverTransport, clientTransport := mcp.NewInMemoryTransports()
server.Connect(ctx, serverTransport, nil)

client := mcp.NewClient(&mcp.Implementation{Name: "desktop-assistant"}, nil)
session, _ := client.Connect(ctx, clientTransport, nil)
list, _ := session.ListTools(ctx, nil) // the same ListTools any external MCP client would call

That means there's physically one server and one list of read-only tools in the codebase — not an original plus a separate copy for the GUI that someone forgets about. In practice, this closes off exactly one class of bug: the one where, six months into a refactor, a tool gets added to one list and someone forgets the other.

Read-only doesn't mean "nothing is visible"

Read-only solves the state-mutation problem, but not the problem of leaking data that's already sitting in the cluster. If the kubeconfig has access to read a Secret in a namespace, then in theory so does the model, by calling get_yaml. This has to be fought at the data layer, not the prompt layer: Secret values get redacted before the YAML ever reaches the tool response —

sec.Data[k] = []byte("<redacted>")

— and the AI (whether the embedded assistant or an MCP client) physically never sees the decrypted value, because it's replaced with a placeholder before the YAML string is even formed. It's also worth rejecting an apply if the YAML still contains <redacted> — otherwise the placeholder could accidentally overwrite a real value.

What this approach doesn't solve

The model can still read a lot of data you already have RBAC access to. Read-only limits what it can do, not what it can see within the same permissions.
Read-only by itself doesn't limit load on the API server from a chatty tool-calling loop either — there are just reasonable measures here (a cap on iterations per conversation, a byte limit on tool results, timeouts on log reads, capped and idle-reaped streams), not some cryptographic guarantee.
If it matters that the prompt and whatever the tools read never leave the machine at all, that's a separate setup (a local model via Ollama/vLLM/LM Studio), not a consequence of the read-only architecture itself.
A compromised registry or altered tool descriptions are a separate story: tool poisoning works against read-only tools too, if the model trusts an instruction inside a description the same way it trusts the system prompt.

The whole approach described here is simple exactly because it deliberately doesn't solve the more general problem — giving an agent any write access at all. If that's genuinely needed (for production debugging with the ability to actually fix something, say), that's a fundamentally different, much heavier architecture: whitelisting specific commands, rate-limiting, role-based restrictions, an immutable audit log with alerts.

Why this isn't tied to a specific model

Since the boundary is the absence of a function, not model behavior, the guarantee works the same regardless of which engine you use — the Anthropic API, an existing Claude Code/Codex CLI login, or a local model via Ollama. You don't have to trust any particular vendor's alignment — the tool registry is the same one for everyone who connects to it, no matter who they are.

If you want to look at the concrete Go implementation, it's open — I added an MCP server to a tool I originally built for myself, and later open-sourced. Repository: https://github.com/cyb3rKn1ght/nereida (cmd/nereida-mcp has a separate README about the MCP server itself).

nereida — a local multi-cluster Kubernetes client I built because on-call kept beating me

Sun, 09 Aug 2026 18:21:08 +0000

It's 2am, an alert fires, and I'm three kubectl config use-context commands deep trying to remember which cluster the broken pod is actually in. My AWS session from an hour ago has expired, so first I have to re-run saml2aws, wait for the browser SSO round-trip, and then start looking for the pod. By the time I've found it, tailed its logs, and confirmed it's not the same one that OOMKilled twenty minutes ago, I've burned five minutes on tooling instead of the incident.

I'm a backend dev who does on-call, not a platform engineer, and I got tired of this specific flavor of friction. I'd used k9s before and liked the idea — one place for everything — but mid-incident I don't want to be recalling which keybinding does what on top of the actual incident. I wanted something just as simple, minus the command-memorizing, that also logged me into AWS/EKS without a separate saml2aws dance, and let me point an LLM at the mess in read-only mode so it could help me reason through what's broken without any risk of it accidentally deleting, scaling, or draining something. So I built nereida: all of that, in one window, with tables and buttons instead of a command palette to memorize.

What it actually does

No commands to memorize. Everything's a table, a click, or a confirmation dialog — cluster switching, log tailing, exec, restarts, all of it. If you've used k9s and liked the "one place for everything" idea but never quite internalized its keybindings, this is the same idea as a GUI instead of a TUI.

One view across clusters. Pick any set of kubeconfig contexts and see Pods, Deployments, StatefulSets, DaemonSets, Jobs, CronJobs, Services, Ingresses, ConfigMaps, PVCs, HPAs, Events, Nodes, and Secrets in unified tables — every row tagged by cluster, so you're not tabbing between windows to figure out where something lives.

One log stream for a workload. Merge logs from every pod behind a Deployment, StatefulSet/DaemonSet, or label selector — with follow, tail/since, timestamps, and previous/init/ephemeral container support. No more opening five terminal tabs to watch five replicas.

Crash context where you need it. Recovered pods show their previous termination right beside the restart count — 3 · OOMKilled (5m ago) — instead of making you dig for it. Nodes surface active memory, disk, and PID pressure.

AWS/EKS SSO without the CLI dance. Native Keycloak SAML SSO login discovers every AWS role your SAML assertion grants and the clusters reachable from each, then writes credentials and kubeconfig entries directly — connect clusters under different roles side by side without one role switch affecting clusters already connected under another. No saml2aws, no AWS CLI. I could have just fixed my saml2aws config instead, but that still leaves you re-running a separate CLI step before you can even open the tool you actually need — this way logging in is opening the tool.

The rest of the toolbox: exec into a container with a real terminal, port-forward with a panel of open tunnels, lifecycle actions (scale, rollout restart/pause/resume, rollback, delete, CronJob trigger/suspend/resume, node cordon/uncordon/drain — each with a confirmation and pinned to the resource UID so a stale name can't hit the wrong object), per-resource YAML editing behind a diff confirmation, and view/context/namespace selections that survive restarts.

Back to that 2am page: this is what it looks like now. One table shows which of the two clusters the pod is actually in, its previous termination already reads OOMKilled instead of me digging for it, and the AWS session is already valid because logging in happened inside the app, not as a prerequisite CLI step before I could even start looking.

The other hook: a read-only AI assistant and MCP server

Separate from the core client, nereida ships an optional AI assistant for diagnosing clusters, plus a standalone read-only MCP server you can point any MCP client at. Bring your own engine — Anthropic API key, your existing Claude Code or Codex CLI login, or any OpenAI-compatible endpoint, including local models via Ollama/vLLM/LM Studio.

The important part: both are read-only by construction. They only register fetch/list/log-streaming tools — there's no scale, delete, drain, edit, or exec tool for a model to call, so there's no path for an AI assistant to change cluster state, however it's prompted.

No accounts, no telemetry, no hosted backend

nereida runs entirely on your machine using client-go — the same library kubectl uses — against your existing kubeconfig, credentials, and RBAC. There's no nereida server in between, no telemetry, no account to create. Secret values stay redacted in the YAML view until you explicitly hit Reveal, and AI tools only ever see redacted values.

The one exception: if you turn on the AI assistant, that turn's prompt and whatever its read-only tools fetch (resource lists, redacted YAML, events, log excerpts) go to whichever model endpoint you configured. Point it at a local model and nothing leaves your machine. Nothing is sent unless you use the AI features — full details in SECURITY.md.

Where it's rough

I'd rather undersell this than oversell it: nereida is early-stage. It's macOS-first (Apple Silicon and Intel, built and used daily there) — Linux x86-64 is best-effort and hasn't had real-world mileage from anyone but me yet, and Windows currently compiles but isn't packaged. The macOS builds are also unsigned for now (no Apple Developer Program cert yet), so first launch needs one workaround — see below.

Installing it

Prebuilt macOS and Linux builds are attached to each release. Since the macOS build is unsigned, first launch needs:

xattr -cr /path/to/nereida.app

(Right-click → Open no longer bypasses this on macOS Sequoia+. If you'd rather skip Terminal: open the app once to trigger the block, then go to System Settings → Privacy & Security, find where it says "nereida" was blocked..., and click Open Anyway.)

To build from source (needed for Windows, or the standalone MCP server): Go 1.26+, Node 20.19+/22.12+, and the Wails CLI.

go install github.com/wailsapp/wails/v2/cmd/wails@v2.12.0
wails build   # app bundle ends up in build/bin/

Why "nereida"?

Nereids are sea nymphs from Greek mythology who protected sailors and calmed storms. Kubernetes means "helmsman" in Greek — the name felt fitting for something meant to make incidents calmer.

It's Apache-2.0 and on GitHub. I built it to solve my own on-call friction, but if it saves you a few minutes mid-incident too, I'd love to hear about it — and if it's useful, a star helps other people find it.