[{"data":1,"prerenderedAt":395},["ShallowReactive",2],{"blog-en-k3s-mcp-ai-agent-rbac-permission-bypass":3,"blog-related-en-k3s-mcp-ai-agent-rbac-permission-bypass":340,"blog-en-k3s-mcp-ai-agent-rbac-permission-bypass-alt":329},{"id":4,"title":5,"author":6,"body":7,"date":323,"description":324,"extension":325,"image":326,"locale":327,"meta":328,"navigation":329,"path":330,"seo":331,"stem":332,"tags":333,"__hash__":339},"blog\u002Fblog\u002Fen\u002Fk3s-mcp-ai-agent-rbac-permission-bypass.md","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","Kubo Team",{"type":8,"value":9,"toc":314},"minimark",[10,15,24,31,55,58,67,71,80,86,95,104,108,116,122,125,189,202,216,220,223,229,246,256,259,263,266,287,296],[11,12,14],"h2",{"id":13},"we-asked-an-ai-agent-to-check-a-pod-and-it-could-delete-it-too","We Asked an AI Agent to \"Check a Pod\" — and It Could Delete It Too",[16,17,18,19,23],"p",{},"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 ",[20,21,22],"strong",{},"mcp-server-kubernetes",", a widely used MCP server implementation.",[16,25,26],{},[27,28],"img",{"alt":29,"src":30},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fk3s-mcp-ai-agent-rbac-permission-bypass\u002Fsection01.webp",[16,32,33,34,38,39,42,43,46,47,54],{},"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 ",[35,36,37],"code",{},"tools\u002Flist"," endpoint, which answers \"which tools are available,\" correctly filtered to read-only tools based on environment variables like ",[35,40,41],{},"ALLOW_ONLY_READONLY_TOOLS",". But the ",[35,44,45],{},"tools\u002Fcall"," endpoint, which actually executes a tool, never checked that same restriction at all (",[48,49,53],"a",{"href":50,"rel":51},"https:\u002F\u002Fneuraltrust.ai\u002Fblog\u002Fkubernetes-mcp",[52],"nofollow","NeuralTrust's CVE writeup",").",[16,56,57],{},"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.",[16,59,60,61,66],{},"For anyone operating a K3s\u002F",[48,62,65],{"href":63,"rel":64},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Freference\u002Faccess-authn-authz\u002Frbac\u002F",[52],"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.",[11,68,70],{"id":69},"why-mcp-kubernetes-is-an-easy-blind-spot-for-permission-design","Why MCP × Kubernetes Is an Easy Blind Spot for Permission Design",[16,72,73,74,79],{},"MCP is an open standard for connecting AI applications to external systems, often described as \"a USB-C port for AI applications\" (",[48,75,78],{"href":76,"rel":77},"https:\u002F\u002Fmodelcontextprotocol.io\u002Fintroduction",[52],"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.",[16,81,82],{},[27,83],{"alt":84,"src":85},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fk3s-mcp-ai-agent-rbac-permission-bypass\u002Fsection02.webp",[16,87,88,89,94],{},"MCP security is generally discussed in terms of five layers: transport\u002Fcommunication, authentication\u002Fidentity, context integrity and confidentiality, authorization\u002Fprivilege management, and supply chain (",[48,90,93],{"href":91,"rel":92},"https:\u002F\u002Faembit.io\u002Fblog\u002Fthe-ultimate-guide-to-mcp-security-vulnerabilities\u002F",[52],"Aembit's MCP security guide","). Within the authorization\u002Fprivilege 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.",[16,96,97,98,103],{},"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\" (",[48,99,102],{"href":100,"rel":101},"https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fsecurity\u002Fsecure-ai-agent-access-patterns-to-aws-resources-using-model-context-protocol\u002F",[52],"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.",[11,105,107],{"id":106},"why-would-a-service-account-that-only-needs-to-view-ever-have-permission-to-delete","Why Would a Service Account That Only Needs to \"View\" Ever Have Permission to \"Delete\"?",[16,109,110,111,115],{},"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 (",[48,112,114],{"href":63,"rel":113},[52],"Kubernetes official RBAC documentation","). Enforcing this principle consistently goes a long way toward preventing over-privileged service accounts for AI agents.",[16,117,118],{},[27,119],{"alt":120,"src":121},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fk3s-mcp-ai-agent-rbac-permission-bypass\u002Fsection03.webp",[16,123,124],{},"Concrete design points break down into three practices:",[126,127,128,158,171],"ul",{},[129,130,131,134,135,138,139,142,143,146,147,138,150,153,154,157],"li",{},[20,132,133],{},"Keep verbs to the minimum required",": an agent that only needs to \"check Pod status\" should be granted ",[35,136,137],{},"get",", ",[35,140,141],{},"watch",", and ",[35,144,145],{},"list"," — never ",[35,148,149],{},"delete",[35,151,152],{},"patch",", or ",[35,155,156],{},"create",".",[129,159,160,163,164,167,168,157],{},[20,161,162],{},"Scope resources to specific types",": avoid blanket declarations like ",[35,165,166],{},"resources: [\"*\"]","; be explicit, e.g. ",[35,169,170],{},"pods",[129,172,173,176,177,180,181,184,185,188],{},[20,174,175],{},"Bound the blast radius with Role and Namespace",": prefer a namespace-scoped ",[35,178,179],{},"Role"," + ",[35,182,183],{},"RoleBinding"," over a cluster-wide ",[35,186,187],{},"ClusterRole"," whenever possible.",[16,190,191,192,197,198,201],{},"K3s's own ",[48,193,196],{"href":194,"rel":195},"https:\u002F\u002Fdocs.k3s.io\u002Fsecurity\u002Fhardening-guide",[52],"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 ",[35,199,200],{},"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.",[16,203,204,205,210,211,157],{},"Red Hat's ",[48,206,209],{"href":207,"rel":208},"https:\u002F\u002Fwww.redhat.com\u002Fen\u002Fblog\u002Fmodel-context-protocol-server-red-hat-openshift-now-available-technology-preview",[52],"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 ",[48,212,215],{"href":213,"rel":214},"https:\u002F\u002Fkubo.hexabase.io\u002F",[52],"Kubo",[11,217,219],{"id":218},"separating-ai-actions-from-human-actions-in-the-audit-log","Separating AI Actions from Human Actions in the Audit Log",[16,221,222],{},"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.",[16,224,225],{},[27,226],{"alt":227,"src":228},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fk3s-mcp-ai-agent-rbac-permission-bypass\u002Fsection04.webp",[16,230,231,232,235,236,241,242,245],{},"Kubernetes audit logging records events generated by ",[35,233,234],{},"kube-apiserver"," — who did what, to what, and when — in JSON Lines format (",[48,237,240],{"href":238,"rel":239},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Fdebug\u002Fdebug-cluster\u002Faudit\u002F",[52],"Kubernetes official audit logging documentation","). Set the audit policy level to ",[35,243,244],{},"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.",[16,247,248,249,252,253],{},"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 ",[35,250,251],{},"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 ",[20,254,255],{},"denies destructive operations like delete specifically when the access came through an AI agent.",[16,257,258],{},"This kind of audit-log separation isn't just for post-incident investigation. In the same way CI\u002FCD 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.",[11,260,262],{"id":261},"conclusion-a-checklist-before-handing-your-cluster-over-to-an-ai-agent","Conclusion: A Checklist Before Handing Your Cluster Over to an AI Agent",[16,264,265],{},"Letting AI agents operate Kubernetes\u002FK3s 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:",[267,268,269,278,281,284],"ol",{},[129,270,271,272,274,275,277],{},"Does the MCP server implementation you're using enforce ",[35,273,37],{}," filtering consistently with the runtime checks in ",[35,276,45],{}," (including whether you're on the latest patched version)?",[129,279,280],{},"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)?",[129,282,283],{},"Is your Kubernetes audit logging configured to distinguish AI agent actions from human operator actions?",[129,285,286],{},"Do you have a mechanism to individually control or deny destructive operations (delete, patch, etc.) specifically when they originate from an AI agent?",[16,288,289,290,295],{},"Embedding AI agents into production infrastructure depends on getting this permission-boundary design right from the start. ",[48,291,294],{"href":292,"rel":293},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fcaptain-ai\u002F",[52],"Captain.AI"," adopts an open architecture built on MCP\u002FSkills 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.",[16,297,298,299,302,303,308,309,157],{},"The foundation underneath all of this is how manageable the Kubernetes cluster itself is to operate. ",[48,300,215],{"href":213,"rel":301},[52]," is a lightweight K3s-based Kubernetes distribution that ships standard with Prometheus\u002FGrafana monitoring and RBAC design best practices, letting you start operating a cluster built for AI-agent integration from as little as ¥48,000\u002Fmonth. If your requirements prohibit data from leaving your premises, ",[48,304,307],{"href":305,"rel":306},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[52],"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 ",[48,310,313],{"href":311,"rel":312},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[52],"Contact Us",{"title":315,"searchDepth":316,"depth":316,"links":317},"",2,[318,319,320,321,322],{"id":13,"depth":316,"text":14},{"id":69,"depth":316,"text":70},{"id":106,"depth":316,"text":107},{"id":218,"depth":316,"text":219},{"id":261,"depth":316,"text":262},"2026-09-03","A real-world MCP permission bypass shows why Kubernetes\u002FK3s clusters need disciplined RBAC design and audit-log separation before letting AI agents operate them.","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fk3s-mcp-ai-agent-rbac-permission-bypass\u002Feyecatch.webp","en",{},true,"\u002Fblog\u002Fen\u002Fk3s-mcp-ai-agent-rbac-permission-bypass",{"title":5,"description":324},"blog\u002Fen\u002Fk3s-mcp-ai-agent-rbac-permission-bypass",[334,335,336,337,338],"k3s","kubernetes","mcp","rbac","ai-agent","HJOGzp5eBv59neoGOUaY3nYOCvYi40DFUVu7sEYoFJU",[341,349,357,365,376,385],{"path":342,"title":343,"description":344,"date":345,"tags":346},"\u002Fblog\u002Fen\u002Fai-agent-authentication-kubernetes-keycloak-spiffe","Don't Hand AI Agents the Keys. A Keyless Design for Authenticating MCP Servers on Kubernetes","Handing AI agents static API keys is an operating model that eventually breaks down. This article explains why static secrets hit a wall when running MCP servers on Kubernetes, and how Keycloak combined with SPIFFE\u002FSPIRE enables a 'keyless' authentication design.","2026-08-18",[334,335,338,336,347,348],"keycloak","zero-trust",{"path":350,"title":351,"description":352,"date":353,"tags":354},"\u002Fblog\u002Fen\u002Fai-agent-sandbox-kata-containers-kubernetes","AI Agent Code Isn't a \"Trusted Product\" Anymore. Kubernetes Sandbox Design Has an Answer","Code generated and executed by AI agents can no longer be treated as a trusted, reviewed product. This article explains the limits of container isolation and why Kata Containers' microVM isolation is becoming essential when designing AI agent sandboxes on Kubernetes.","2026-08-08",[334,335,355,338,356],"kata-containers","security",{"path":358,"title":359,"description":360,"date":361,"tags":362},"\u002Fblog\u002Fen\u002Fkubernetes-secrets-rbac-etcd-encryption","Base64 Isn't Encryption: Why Kubernetes Secrets Pass Right Through, and the RBAC Design Traps That Make It Worse","Kubernetes Secrets are only Base64-encoded, not encrypted. Learn how plaintext-equivalent storage in etcd and over-permissioned RBAC lead to real incidents, plus the concrete Secrets management practices you need for production K3s.","2026-07-29",[335,334,363,337,356,364],"secrets-management","etcd-encryption",{"path":366,"title":367,"description":368,"date":369,"tags":370},"\u002Fblog\u002Fen\u002Fk3s-local-path-provisioner-capacity-node-affinity-pvc-pending","Your K3s Pod Won't Leave Pending. The 'Ignored Capacity' and Node Affinity Trap in Local Storage","A K3s PVC stuck in Pending often traces back to one fact: local-path-provisioner never enforces capacity limits. This post digs into hypervisor thin provisioning, Volume Node Affinity Conflicts, and the backup misconceptions hiding in K3s local storage design.","2026-09-12",[334,335,371,372,373,374,375],"storage","local-path-provisioner","persistent-volume","node-affinity","zfs",{"path":377,"title":378,"description":379,"date":380,"tags":381},"\u002Fblog\u002Fen\u002Fk3s-keda-vs-hpa-event-driven-autoscaling-decision","KEDA vs HPA on K3s: A Decision Framework for Event-Driven Autoscaling","When CPU\u002Fmemory-based HPA on K3s can't keep up with event-driven workloads, should you extend HPA or adopt KEDA, the CNCF-graduated project? Here's a 3-point decision framework, plus what to watch for on K3s.","2026-09-10",[334,335,382,383,384],"hpa","keda","autoscaling",{"path":386,"title":387,"description":388,"date":389,"tags":390},"\u002Fblog\u002Fen\u002Fk3s-proxmox-live-migration-etcd-quorum-affinity-design","Proxmox Live Migration Quietly Breaks K3s etcd Quorum: When Virtualization Collides with Raft","A deep dive into how live-migrating a K3s control plane VM on Proxmox can break etcd quorum, explained through heartbeat\u002Felection-timeout mechanics and Proxmox affinity design, with concrete operational countermeasures.","2026-09-09",[334,335,391,392,393,394],"proxmox","etcd","live-migration","high-availability",1792488904220]