A man in a blue shirt works at a laptop on a wooden counter, photographed from above. Photo by Samuel Sianipar on Unsplash. Source: https://unsplash.com/photos/man-using-laptop-on-desk-Mad2smykZU0 (Unsplash License).

Executive Summary

CIQ released Stratum Kubernetes Engine in technical preview on 29 October, an Apache 2.0 Kubernetes distribution built from unmodified upstream by the team behind Rocky Linux and Warewulf. It ships about ten upstream projects as one signed file, pins and tests them as a set, checks node health at each step of a rolling upgrade, snapshots etcd every 12 hours by default and renews certificates before they expire. General availability is expected on 5 November.

The part worth studying is the agent surface. A built-in MCP server exposes its tools across three tiers, and the tier is fixed when the server process starts. A tool above the enabled tier is never registered, so the client never learns it exists. CIQ’s own documentation is blunt that the flags are not a security boundary and that Kubernetes RBAC is. Secrets are refused at every tier, and the server will not write RBAC or admission control. The design is better than most agent integrations shipped this year. The exposure it leaves is operator habit.

The most important line in CIQ’s new Kubernetes distribution is not about Kubernetes. It is about what the tool server will admit exists. When an agent drives a cluster, what decides incidents is which capabilities it was ever told about.

CIQ Stratum Kubernetes Engine (SKE) shipped as free and open source under Apache 2.0 on 29 October, with general availability expected on 5 November, per CIQ’s release. It comes from the team that maintains Rocky Linux, Warewulf and Apptainer, and it targets operators who run Kubernetes beside HPC and GPU hardware rather than instead of it.

A tool the client never sees cannot be argued around

The stratum mcp command starts a Model Context Protocol server on stdio. With no flags it registers 19 tools that read cluster and node state. The allow-write flag adds eight that apply manifests, scale workloads, take a snapshot and mint node join tokens. The allow-destructive flag adds eleven more that upgrade, roll back, rotate certificate authorities, restore etcd and uninstall. The flags are independent, so enabling the destructive tier does not quietly enable writes.

Diagram of the CIQ Stratum MCP capability tiers. No flags registers 19 read tools. The allow-write flag adds 8 tools for manifests, scaling, snapshots and join tokens. The allow-destructive flag adds 11 tools for upgrade, rollback, CA rotation, etcd restore and uninstall. Kubernetes RBAC remains the hard boundary.
Nineteen read tools by default. The other two tiers are opt-in at process start, and nothing above them is registered at all.

CIQ’s documentation explains the reasoning. A tool that appeared and then refused an action would tell the model the capability exists and invite it to find another route to the same effect. So the tools above the enabled tier are not filtered out of a response. They are never registered. That is a different control from a system prompt, and it survives a model that ignores instructions.

The read tier is shaped for agents too. Every list is bounded, there is no kubectl passthrough, and results arrive fenced inside untrusted-data markers with a random id per call, because a log line can contain text written to look like an instruction.

The flags are not the boundary and CIQ says so

CIQ states the limit plainly. Kubernetes RBAC is the only hard boundary. The tiers decide what the server offers, and RBAC decides what the credential is allowed to do. A server started with no flags but running as cluster-admin is one misconfiguration away from full cluster access.

A few local-admin tools ignore the server credential entirely. Token listing, upgrade planning and one hardening operation run on the node’s own internal credential, so for those the flag and root are the only controls. The HTTP transport carries no authentication and binds to loopback.

None of this is a flaw. It is a product that documents its own weak points. The risk sits where it always sits. An operator points the server at admin.conf because that works, and the tier flags become the only thing between an agent and the cluster. CIQ’s answer is a ServiceAccount with the narrowest role that works, plus two auth checks that should both answer no.

One signed file answers the boring half of the problem

CIQ’s pitch is drift. Running Kubernetes in production still means assembling about ten upstream projects that each release on their own schedule, and SKE ships them pinned and tested as a set. etcd snapshots run every 12 hours, certificates renew before expiry, and every release is signed and carries a bill of materials.

The numbers CIQ uses to size that problem are in the release. Kubernetes runs in production at 82 percent of organizations that use containers, and two thirds of organizations hosting generative AI models run some or all inference on it, per the January 2026 CNCF survey. In a survey of 785 Kubernetes decision makers, 62 percent said complexity was slowing initiatives and 65 percent ran air-gapped clusters. Air-gapped is what makes a signed binary more than a convenience.

Three questions for your own cluster. If an agent could reach your control plane today, which service account would it use? Which of your day-two operations would you refuse to expose even with a read flag? And who checks that the credential still matches the tier after the next Friday afternoon change?

Related reading. A web page dropped a file in Downloads and Codex ran it nine times, and Google built an agent sandbox with nothing inside worth stealing.

By Ivan Tarin

Ivan Tarin is a Principal Product Marketing Manager at SUSE, where he owns go-to-market strategy and positioning for a seven-product cloud-native portfolio spanning Kubernetes, virtualization, storage, security, and observability. A former full-stack developer who shipped production code for enterprise and public-sector clients including U.S. national laboratories, Ivan translates complex infrastructure and AI technology into messaging that lands with developers, platform teams, and enterprise buyers. He has presented at KubeCon, SUSECON, and AWS Developer Week, and is currently pursuing an MS in Artificial Intelligence at the University of Colorado Boulder.

Leave a Reply

Your email address will not be published. Required fields are marked *

Get the next one before it is old news

Independent analysis of cloud-native infrastructure, Kubernetes and data center economics. No vendor spin.