Agentic Kubernetes

Agentic Kubernetes is Kubernetes operated by, or built to host, autonomous AI agents. These are programs that observe the state of a cluster, reason about what they see, and take multi-step action over the Kubernetes API without a human approving each step. The term covers two different things that are easy to confuse. One is running agents on a cluster. The other is letting an agent operate the cluster. A platform built for agentic Kubernetes supports both.

What is agentic Kubernetes?

Kubernetes already automates a great deal. Controllers reconcile desired state, operators encode runbooks, and AIOps tools raise alerts. An agent differs from all three in its loop: it observes, reasons with a language model, acts, and observes again, and it can carry a goal across many steps and many tools. Point one at a cluster and it can triage a crash looping pod, propose a fix, apply it, and check the result.

That capability changes what a cluster needs to provide. A controller only does what its code says. An agent does what its tools allow and what its context persuades it to do, and some of that context comes from the cluster itself: pod logs, annotations, ConfigMap values, and event messages that anyone with write access to a workload can shape.

Agents on the cluster versus agents operating the cluster

Agents on the cluster are workloads. They need isolation, because agent code often runs tools and fetches content it did not write. They need identity and state, because an agent session can last hours. Projects such as Agent Sandbox, from Kubernetes SIG Apps, give each agent an isolated, stateful pod with a stable identity through a secure runtime such as gVisor or Kata Containers. Frameworks such as kagent, a CNCF project, define agents as Kubernetes custom resources with a controller, a UI, and an MCP toolbox. Both install onto an existing cluster.

Agents operating the cluster are clients of the API. They act through a Model Context Protocol (MCP) server that exposes cluster operations as tools, with a Kubernetes credential behind it. The questions here are different: which tools exist, what the credential can do, what is refused no matter what, and whether the text the cluster returns can steer the model.

What a cluster needs to be agent-safe

• Tiered permissions, decided before the session starts. Read tools by default; write and destructive tools behind separate, explicit switches. Tools above the enabled tier should not be registered at all, so the model never learns they exist.
• Least privilege at the credential. The MCP server runs as a dedicated service account that cannot read Secrets or write role bindings, verified with kubectl auth can-i before any agent connects. Tiers decide what the agent is offered; RBAC is the hard boundary.
• Hard refusals. Some operations should be refused at every tier, however the server was started: Secret reads, RBAC writes, admission webhooks, and pod specs that escalate privilege or mount Secrets.
• Untrusted-data fencing. Every result the server returns should be marked as data, not instructions, with a marker the model cannot be tricked into closing early. This is the defense against prompt injection carried in logs and object metadata.
• An audit trail. Every action the agent takes should be attributable to the agent's own identity, which is one more reason not to run it as the cluster admin.

Where CIQ Stratum Pro fits

CIQ Stratum Pro is built on CIQ Stratum Kubernetes Engine (SKE), an engine that installs from one signed binary on Enterprise Linux 9 or later, including Rocky Linux. It has a built-in MCP server, stratum mcp, which ships in SKE and starts read-only. Write and destructive tiers are separate flags, Secret reads and RBAC writes are refused at every tier, and every result is wrapped in untrusted-data markers with a random id chosen per call. Agent frameworks such as kagent and Agent Sandbox run on an SKE cluster like any other, so one cluster covers agents on it and agents operating it. Our guide to the best Kubernetes for AI agents compares CIQ Stratum Pro with K3s, RKE2, OpenShift, and kubeadm on tiers, Secrets, and prompt-injection fencing.

Agentic Kubernetes versus related terms

	Agentic Kubernetes	Operators and controllers	AIOps
Decides what to do	A language model, from a goal and the cluster state	Code written in advance	Statistical models over telemetry
Acts on the cluster	Yes, through tools over the API	Yes, within the resource it owns	Usually recommends; acting is a separate step
Takes input from	Cluster state, logs, and tool results, all untrusted	Its own resource spec	Metrics, logs, and traces
Main safety question	What the agent is allowed and persuaded to do	Whether the code is correct	Whether the signal is real