We Asked an AI Agent to 'Check a Pod,' and It Took Over the Entire K3s Cluster: What an MCP Server's Permission Bypass Teaches Us About RBAC Design

We Asked an AI Agent to "Check a Pod" — and It Could Delete It Too

With MCP (Model Context Protocol), you can simply tell an AI agent "check the status of this Pod" and let it look around inside your Kubernetes cluster. But permissions that were meant to be read-only have, in practice, allowed deletion and restarts as well — and this actually happened in mcp-server-kubernetes, a widely used MCP server implementation.

This MCP server sees over 20,000 weekly downloads on npm and has earned more than 1,400 stars on GitHub. The vulnerability found here (CVE-2026-46519, CVSS score 8.8) had a surprisingly simple root cause. The tools/list endpoint, which answers "which tools are available," correctly filtered to read-only tools based on environment variables like ALLOW_ONLY_READONLY_TOOLS. But the tools/call endpoint, which actually executes a tool, never checked that same restriction at all (NeuralTrust's CVE writeup).

In other words, even when an AI agent's view was limited to "only read-only tools visible," it could still invoke destructive tools directly as long as it knew the tool name. The front door looked properly locked, but the back door — the execution path — had no lock at all. The issue has been fixed since version 3.6.0, but the underlying lesson persists: "restricting what's visible" and "restricting what's executable" are implemented as separate layers, and that gap is a recurring trap whenever teams build or customize their own MCP servers.

For anyone operating a K3s/Kubernetes cluster, this isn't someone else's problem. The moment you grant an AI agent MCP access with the casual intent of "just let it look around and report back," the design of that agent's execution permissions determines whether your entire cluster is put at risk.

Why MCP × Kubernetes Is an Easy Blind Spot for Permission Design

MCP is an open standard for connecting AI applications to external systems, often described as "a USB-C port for AI applications" (Model Context Protocol official docs). It's built from three components — a host (the AI application itself), an MCP client, and the MCP server that actually provides tools — and an LLM can chain multiple tool calls while carrying context forward. Ask "check the Pod's status," and in the very next message just say "okay, restart it" — the LLM will infer which Pod you mean from prior context and chain that into a real Kubernetes API operation. This convenience is exactly what makes MCP valuable, and exactly what makes it risky.

MCP security is generally discussed in terms of five layers: transport/communication, authentication/identity, context integrity and confidentiality, authorization/privilege management, and supply chain (Aembit's MCP security guide). Within the authorization/privilege layer specifically, agents and tools tend to be granted broader permissions than they actually need. Once an over-privileged identity is compromised even once, it becomes a powerful foothold for deeper intrusion. Because MCP architectures consist of interconnected workflows, a single vulnerability can cascade into an incident affecting the entire system.

AWS's own security guidance reaches the same conclusion: "Because agents are non-deterministic and act on runtime reasoning rather than fixed logic, you should assume that any permission granted will eventually be exercised" (AWS Security Blog). A human operator carries an implicit sense of "surely I wouldn't do that" — but that assumption doesn't hold for AI agents. Permissions you grant should be designed as if they will, someday, actually be used. If you're going to let an AI agent genuinely "work" as part of your organization rather than merely "use" it, defining permission boundaries can't be an afterthought — it has to be a precondition set at the very start of the integration.

Why Would a Service Account That Only Needs to "View" Ever Have Permission to "Delete"?

Even if the MCP server implementation itself has no vulnerabilities, a loosely designed service account — the one the MCP server uses to reach the Kubernetes API — carries the same risk. Kubernetes RBAC is an additive permission model built on "deny by default": anything not explicitly allowed is denied (Kubernetes official RBAC documentation). Enforcing this principle consistently goes a long way toward preventing over-privileged service accounts for AI agents.

Concrete design points break down into three practices:

• Keep verbs to the minimum required: an agent that only needs to "check Pod status" should be granted get, watch, and list — never delete, patch, or create.
• Scope resources to specific types: avoid blanket declarations like resources: ["*"]; be explicit, e.g. pods.
• Bound the blast radius with Role and Namespace: prefer a namespace-scoped Role + RoleBinding over a cluster-wide ClusterRole whenever possible.

K3s's own official hardening guide recommends explicitly creating a dedicated service account whenever a workload needs specific API access, and disabling automatic token mounting for the standard default service account. The guide also states plainly that "these policy-related controls are not enforced by K3s by default — enforcing them is the operator's responsibility." Leaving an MCP server's service account on the default settings "just for now" runs directly against this principle.

Red Hat's MCP server for OpenShift (currently a technology preview) embodies this idea at the implementation level. It respects standard Kubernetes RBAC as-is, disables destructive operations by default, and requires administrators to explicitly opt in before any write capability becomes available. Defaulting to read-only and making write access opt-in is a design pattern that translates directly to designing AI agent integrations on K3s-based managed clusters like Kubo.

Separating AI Actions from Human Actions in the Audit Log

Even with minimized permissions, incident response falls behind if you can't trace what was actually executed. What matters here is being able to distinguish, in the audit log, between actions taken by an AI agent and actions taken by a human operator.

Kubernetes audit logging records events generated by kube-apiserver — who did what, to what, and when — in JSON Lines format (Kubernetes official audit logging documentation). Set the audit policy level to Metadata or higher, and the user-agent information included in request headers gets captured too. Red Hat's MCP server for OpenShift takes advantage of exactly this mechanism, injecting a dedicated user-agent string into API calls issued by the AI agent so that AI-driven and human-driven operations can be clearly separated in the audit log.

AWS's security guidance describes a similar approach. If you're going through an AWS-managed MCP service, you can key off a condition like aws:ViaAWSMCPService; for a self-hosted MCP server, session tags let you determine "was this access made by an AI agent." What matters is building this distinction in ahead of time rather than reconstructing it after the fact — for example, a policy that denies destructive operations like delete specifically when the access came through an AI agent.

This kind of audit-log separation isn't just for post-incident investigation. In the same way CI/CD and GitOps workflows track "who deployed this change, and when," AI-agent cluster operations need the same level of traceability. Only once that's in place does it become operationally sound to delegate part of your cluster operations to an AI agent.

Conclusion: A Checklist Before Handing Your Cluster Over to an AI Agent

Letting AI agents operate Kubernetes/K3s clusters via MCP has been spreading rapidly through 2026. But as CVE-2026-46519 showed, "which tools are visible" and "which tools are executable" aren't necessarily enforced at the same layer. Before connecting an AI agent to a production cluster, check at minimum the following four points:

1. Does the MCP server implementation you're using enforce tools/list filtering consistently with the runtime checks in tools/call (including whether you're on the latest patched version)?
2. Is the MCP server's service account bound to a Role that grants only the verbs and resources it actually needs (avoiding casual use of ClusterRole)?
3. Is your Kubernetes audit logging configured to distinguish AI agent actions from human operator actions?
4. Do you have a mechanism to individually control or deny destructive operations (delete, patch, etc.) specifically when they originate from an AI agent?

Embedding AI agents into production infrastructure depends on getting this permission-boundary design right from the start. Captain.AI adopts an open architecture built on MCP/Skills while aiming to let organizations control precisely "what" an AI agent can touch and "how far" — treating permission design as a first-class concern rather than an afterthought, as AI shifts from something you merely "use" to something that genuinely "works" as part of your team.

The foundation underneath all of this is how manageable the Kubernetes cluster itself is to operate. Kubo is a lightweight K3s-based Kubernetes distribution that ships standard with Prometheus/Grafana monitoring and RBAC design best practices, letting you start operating a cluster built for AI-agent integration from as little as ¥48,000/month. If your requirements prohibit data from leaving your premises, Kubo On-Premise lets you apply the same operating model in a fully air-gapped environment. If you'd like to discuss infrastructure built for a future where AI agents operate your clusters, feel free to reach out via Contact Us.