Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Fleets of robots, drones, EV chargers, and sensors now run K3s or MicroK8s on the device itself, bringing container orchestration to hardware deployed in warehouses, cell towers, and customer sites around the world. Engineers need kubectl to debug and manage containerized workloads on those devices in the field. But because each cluster requires a kubeconfig file, and every kubeconfig file is a shared static credential, risk grows with each new device added to the fleet.

Most attempts to control AI agents work at the model layer (alignment, system prompts) or the application layer (guardrail libraries, output filters). Both share a flaw: the thing being secured is also the thing doing the securing. A sufficiently confused or sufficiently compromised agent can talk its way past its own instructions. OpenShell takes a different position, and it is the right one. Put the controls in the environment, where the agent cannot negotiate with them.

As Kubernetes clusters scale from a few development sandboxes to massive, multi-tenant production environments, platform teams often find themselves facing a configuration management crisis. A small number of microservices suddenly demand hundreds of individual Kubernetes NetworkPolicy objects. Managing them becomes operationally expensive, auditing them is difficult, and a single developer misconfiguration can easily drop critical production traffic or open a massive security hole.

In Part 1 of this series, we addressed 18 Kubernetes best practices spanning across container hardening, observability, availability, and fault tolerance. Those practices secure the containers that agents run in. But the CNCF AI Technical Community Group's cloud-native agentic standards go further, establishing that securing containers is only the beginning.

TL;DR: Aikido now supports Docker Hardened Images. A scan that used to return hundreds of CVEs collapses to the handful that actually apply, because Docker's VEX attestations filter out everything they've verified as non-exploitable. Zero additional setup. Container security has a noise problem You scan a container image and get back a list of 50, 100, sometimes hundreds of CVEs. You open a few. Some look scary. Most are irrelevant. Some have already been patched by the image maintainer.

As part of our work at Tigera building products that create secure runtime environments for enterprise agents at scale in the real world, one small part of this puzzle I think about a lot is policy, and runtime enforcement of policy, and how to create a comprehensive secure runtime, configured from one place.

Running one Kubernetes cluster is complex enough. Running five across AWS, GCP, and an on-prem data center without a unified control plane gets painful fast. Kubernetes Federation v2 (KubeFed) was built to solve this problem: managing federated Kubernetes clusters from a single point of control and distributing workloads across regions and providers without duplicating YAML files for every environment.

An AI agent moving laterally through a Kubernetes cluster does not look like an intrusion. There is no foreign process, no exploit, no dropped binary — just the agent using the identity, network routes, and tools it was handed at deployment to reach targets it was technically allowed to touch. That is the entire problem. The controls you run were built to catch an outsider pivoting from host to host.

A few weeks ago I was on a call with a financial services customer who had moved a credit-decisioning model into production on Red Hat OpenShift AI. They were happy with the platform. They were less happy with the answer they had for a question their risk officer had just asked: “If an attacker encrypts the cluster tomorrow, what do we need to bring back to be inference-ready by Monday morning?” The team started listing the obvious things — the model artifact, the serving endpoint.