Posted on August 19, 2026 by Koray Oksay | CNCF Ambassador Where does Kyverno live in your organization? I don't mean which cluster! On which team's slide deck does it show up? For most companies I've talked to, the answer is security. Kyverno is evaluated alongside OPA/Gatekeeper, approved by the security team, deployed with a bundle of Pod Security Standard policies, and then… mostly sits there, blocking the occasional root container. Meanwhile, the teams actually getting interesting value out of Kyverno are the ones doing things with it that make me stop and take notes. These are almost never security teams.
And I don't think that's a coincidence. I think we've filed Kyverno in the wrong mental category, and that miscategorization is costing us access to most of what the tool can do. I've been circling this observation for a while. My first Kyverno conference talk, back at KCD Munich 2023, was literally titled "Securing Your Kubernetes Workloads with Kyverno" — I was filing it in the security drawer myself.
Three years of production work later, my talks are about governance, CEL, and platform self-service, and my post on the Platform Engineering blog argued that Kyverno has outgrown "policy engine" as a description entirely. This post is me finally putting the underlying claim in one sentence, and it's the opening argument of a longer series on policy-driven platform engineering: Kyverno is a platform primitive. Not a security tool that platform teams happen to use. A building block for platforms, in the same sense that Pods and Services are building blocks, that happens to also be useful for security.
Let me be clear about what I'm not saying. Kyverno absolutely does security work. It blocks insecure configs, it enforces PSS, it verifies image signatures. If your CISO asks whether it helps with compliance, the answer is yes, genuinely. But "security tool" carries a specific mental model with it: policy as a gate . Something bad shows up, the gate stops it. The primary verb is deny . Success gets measured in blocked deployments. Now look at what Kyverno actually does. Four things: validate, mutate, generate, verify images. Only the first one fits the gate model.