Operations | Monitoring | ITSM | DevOps | Cloud

In Kubernetes, pods get a new IP every time they restart, so an IP can’t tell you which workload it is. Platform teams learned to identify workloads by labels and identity instead. AI agents are now teaching them a second lesson: an agent’s code can’t tell you what it will do. I believe AI agents belong on the Kubernetes platform. Not beside it, not around it, and not left to each team to secure alone. On it: identified, governed and contained like every other production workload.

We’re pleased to announce that Calico is supported on Red Hat OpenShift 5, the latest version of the industry’s leading hybrid cloud application platform powered by Kubernetes. Tested and validated to run on Red Hat OpenShift 5, Calico delivers high-performance networking and zero-trust network policy for containers, virtual machines on Red Hat OpenShift Virtualization, and AI workloads, with one consistent policy model across the cluster.

Over the past year, I’ve spent a lot of time talking with engineering and platform teams about how they’re deploying AI agents. The conversations are changing. Six months ago, most were focused on getting agents into production. Now, increasingly, the question is how to secure them once they’re there. It’s a familiar transition. We’ve seen it with containers, Kubernetes, microservices, and cloud infrastructure.

In short, in the five weeks to 27th October 2026, Okta, Satya Nadella, the Cloud Security Alliance and Salesforce each put the words “kill switch” or “emergency brake” next to AI agents, and the AI Kill Switch Act, introduced in the US House on 23rd July, would require the largest model providers to be able to throttle, suspend or shut their systems down on order. Every one of those switches stops something, and none of them stops the same thing.

TL;DR: Google Cloud’s post of 22nd July 2026 on why AI apps fail in production describes how a YouTube team gets AI prototypes in front of user research in weeks instead of quarters: a prototyping stack that hands each prototype read-only access to live production data through a proxy, keeps its code out of the production binary, and throws the prototype away once the idea is proven.

In short, automating the AI agent lifecycle is this year’s pitch: Google Cloud’s walkthrough of 30th July 2026 turns the whole thing into a conversation with a coding agent.

In short, healthcare is adopting AI agents faster than almost any other industry. More than 85% of Epic’s customers already use Epic AI, Epic’s Agent Factory will let every health system build agents of its own from 2027, and 43% of health systems were piloting agentic AI at the start of this year.

At Tigera, we spend a lot of time thinking about agent security: identity, policy, runtime controls, and the record left behind after an agent acts. Coding agents create an interesting problem because, in most organizations, they didn’t arrive through the front door. Few companies ran a platform evaluation and rolled Claude Code out to 500 developers. Developers installed it themselves.

Jamin Ball’s recent piece, “Systems of Record Won the SaaS Era — Clearinghouses Will Win the Agents Era,” is the cleanest articulation I’ve seen of where the durable moat goes next. His argument is simple and, I think, correct: the SaaS era rewarded whoever owned the system of record, and the agent era will reward whoever owns the clearinghouse.

Human approval is easy when you are sitting in front of the agent. For an agent running by itself in a cluster, almost none of that holds. You’re in a meeting and your agent is running in a cluster. It has a service account, it has been asked to keep a service healthy, and it has just worked out that the right fix is to roll back a database migration. Nobody is watching it. That was rather the point of deploying it. You want to get notified to approve such an important action.