Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Run any mature scanner against a container image you built yesterday, and you will likely see dozens — sometimes hundreds — of CVEs. Most of them sit in code you never wrote. That is the uncomfortable reality container image scanning exists to deal with: modern images are assembled from layers of inherited software, and every layer carries someone else’s vulnerabilities into your production environment.

EU regulations are putting real pressure on how organizations protect and recover their data. If you run Kubernetes workloads in financial services, insurance, healthcare, energy, telco, and public administration, your backup strategy is no longer just an IT concern. It is something regulators and auditors can examine directly. Most Kubernetes environments were set up for operational convenience rather than compliance.

In short, the MCP 2026-07-28 release candidate is getting attention for going stateless. The quieter story is a package of six SEPs that harden the protocol’s OAuth layer: issuer validation, credential binding, client type declaration, and cleanups around refresh tokens, scopes, and discovery. All six are worth shipping, and all six fix real failure modes. But they harden how a client authenticates to a server, and that was never the whole problem.

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.