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.
I’ve spent the last decade working with the platform teams behind some of the largest Kubernetes environments in the world: banks, telecom carriers, SaaS companies and insurers. I watched them take containers from a side experiment to the default way their companies ship software. The best of them did it without slowing anyone down, and without giving up control.
This year I’m watching the same story start again with a new workload. AI agents are arriving on those platforms faster than anyone can govern them. In an April 2026 Cloud Security Alliance survey of 418 IT and security professionals, 82% said they had found at least one AI agent or autonomous workflow in the past year that their security or IT team didn’t know existed (CSA).
Speed versus control is a false choice
Right now three teams are pulling in different directions. AI teams are racing to ship agents. Platform teams own the clusters those agents run on, but most agents weren’t onboarded through them. Security is asked to approve workloads it can’t see.
The result I hear about most often isn’t a breach. It’s an agent that’s finished and stuck in review.
I’ve seen this standoff before. A decade ago it played out over containers, and the platform teams that won didn’t pick a side. They built a paved road: fast for developers, safe for security, and owned by the platform. Agents need a similar road.
What makes agents harder is that they make runtime decisions by themselves. They choose at runtime which model, tool or other agent to call, and they act on someone’s behalf with credentials that are perfectly valid. An agent can be correctly authenticated, correctly authorized, and still be doing the wrong thing.
Five lessons that carry over
The good news is that the playbook already exists. The platform teams I admire most learned it on containers, and every lesson holds for agents. None of them holds unchanged.
- Know what’s running. Kubernetes platforms always knew, because everything came through the pipeline. Agents don’t, so finding them becomes the first control, not a report.
- Secure identity, not addresses. We stopped trusting IP addresses years ago. Now the question is which agent made a call, for whom, and with what authority.
- Write policy for intent. Policy has to speak in tools and data, live in version control like code, and earn trust in observation before it enforces.
- Never trust a single layer. A checkpoint on every call is necessary, but an agent can go around it. Something has to hold the agent once the call is allowed.
- Guardrails, not gates. Limits security agrees once, applied to every new agent automatically, with no code changes. That’s how security gets to yes faster.
Peter Kelly, our CTO, goes deeper on how each of these five lessons works in practice in his post.
What I’m hearing from customers
In my conversations with platform, AI and security leaders this year, the same things keep coming up.
A global healthcare company told me their first problem isn’t policy. It’s finding the agents nobody approved. A services firm that runs agent platforms for large banks expects to manage 5,000 to 10,000 agents, and its biggest worry is teams routing traffic around the central gateway. A trading firm that had already built its own AI gateway told me the gateway was the easy part. What they wanted was the layer underneath, and they’d rather buy it than build it.
And almost everyone said the same thing about culture: business units push back on any rule that forces a specific SDK into their code. Controls that need no code changes are the ones that get adopted.
Why Tigera secures AI agents
These are the market drivers that have led us to secure AI Agents and the Kubernetes clusters they run on. We’ve spent a decade earning the trust of platform teams through Project Calico, which secures more than 8 million Kubernetes nodes every day. Lynx is how we bring that to AI agents.
Lynx finds every agent, including the ones nobody registered. It puts a gateway in the path of every call to a model, a tool or another agent. And it holds any agent at the kernel, including one that skips the gateway, so that one agent can be contained without taking down its tenant. It runs in your clusters, alongside whichever CNI you already use, with no changes to agent code.
Three questions for every platform leader
When I meet a head of platform or a CIO, I ask three questions:
- How many AI agents are running on your clusters right now?
- Pick one agent call from yesterday. Can you say which agent made it, for which user, and which policy allowed it?
- Can you stop one agent without taking down everything around it?
If your team can answer all three today, you’re ahead of most companies I talk to. If not, that’s where I’d start.
What I’m still watching
Two questions will shape the next few years. First, agents don’t live only in Kubernetes. Security teams want one view of agent risk across desktops, SaaS and cloud, and the cluster has to feed that view rather than become one more console. Second, nobody has a good answer yet for retiring agents. Projects end, but agents and their credentials often don’t.
Platform teams already learned that an IP address can’t tell you which workload it is. Now they’re learning that an agent’s code can’t tell you what it will do. The teams I work with already know how to handle a shift like this, because they’ve done it once. The playbook is the same. The workload is new.
