Letting an AI Agent Talk to Your Kubernetes Cluster: The Guardrails MCP Servers Don't Give You by Default

What changed

Red Hat is building an open-source MCP (Model Context Protocol) server extension aimed at letting AI assistants manage Kubernetes and OpenShift clusters directly — querying resource state, applying manifests, and running the kind of operational tasks a platform engineer would normally run through kubectl. It's part of a broader trend: MCP has become the default way to wire an AI agent into infrastructure tooling, and cluster management is one of the more consequential places that's happening, because the blast radius of a wrong command is a production outage, not a bad code suggestion.

This is a genuinely useful capability — "ask the agent to diagnose why this pod is crash-looping and it queries the cluster directly" is a real time-saver over copy-pasting kubectl describe output into a chat window. But an MCP server that can read cluster state can usually also write it, and the default configuration of "give the agent a kubeconfig" grants far more than most tasks need.

The default failure mode

The most common mistake we see is pointing an MCP server at a kubeconfig with cluster-admin, because it's the fastest way to get the integration working in a demo. That's fine for a local kind cluster; it's not fine for anything touching production, for the same reason you wouldn't give a CI runner cluster-admin just because it's convenient. The agent inherits every permission the credential has, including ones no task you're planning to ask it for actually needs.

Guardrail 1: scope the ServiceAccount to what the agent is actually for

Create a dedicated ServiceAccount and RBAC role for the MCP server's identity — not the human operator's kubeconfig, and not cluster-admin.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: mcp-agent-readonly
  namespace: production
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log", "events"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: mcp-agent-readonly-binding
  namespace: production
subjects:
  - kind: ServiceAccount
    name: mcp-agent
roleRef:
  kind: Role
  name: mcp-agent-readonly
  apiGroup: rbac.authorization.k8s.io

Start read-only. Diagnosis and investigation cover the majority of what teams actually want an agent doing against a live cluster, and read-only access means a bad or hallucinated command can't do damage — it just returns an error or wrong-but-harmless output.

Guardrail 2: separate write access into its own explicitly-granted role, per namespace

If you do want the agent to apply changes — restarting a deployment, scaling a replica count — put that in a second Role scoped to exactly those verbs and resources, bound only in the namespaces where it's needed. Never grant cluster-wide write access to an agent identity; namespace-scoped RoleBindings mean a mistake in a staging namespace can't reach production, even if the same MCP server instance is technically capable of talking to both.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: mcp-agent-restart-only
  namespace: staging
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "patch"]
    resourceNames: [] # consider scoping to specific deployments if the task set is known

Guardrail 3: audit every write the agent identity makes

Kubernetes audit logging can filter on a specific ServiceAccount, which means you can get a clean, isolated trail of everything the agent actually did versus what a human operator did — critical both for debugging an incident the agent may have caused and for building the trust needed to expand its scope later.

# audit-policy.yaml excerpt
- level: RequestResponse
  users: ["system:serviceaccount:production:mcp-agent"]
  verbs: ["create", "update", "patch", "delete"]

Guardrail 4: treat the MCP server itself as an attack surface

The MCP server process holds the credential and mediates every call the agent makes — if it's compromised or misconfigured, the RBAC scoping on the ServiceAccount is your only remaining control. Run it in its own namespace, apply a NetworkPolicy restricting its egress to the Kubernetes API server, and don't expose it on a shared network segment with unrelated workloads.

Start every MCP-to-cluster integration read-only, and add write scopes one capability at a time as you build confidence.
Never bind an agent identity to cluster-admin, even temporarily "to get it working" — scope it from the first deployment.
Turn on audit logging filtered to the agent's ServiceAccount before granting any write access, not after the first incident.
Keep the MCP server's blast radius equal to what you'd accept from a junior engineer's first week of kubectl access, not what you'd hand a senior SRE.

The capability itself is worth adopting — cluster-aware AI assistance genuinely speeds up diagnosis and routine operations. The risk isn't the integration; it's skipping the RBAC design work because the demo worked with a kubeconfig that had more access than the task needed.