On August 19, 2026, CNCF Ambassador Koray Oksay published a widely discussed post arguing that Kyverno, the Kubernetes-native policy engine, is organizationally miscategorized at most companies. Kyverno lets teams write policies as ordinary Kubernetes YAML, rather than a separate policy language like Rego, to validate, mutate, and auto-generate resources as they are applied to a cluster. Oksay's argument is that most organizations file it under security ownership and budget, which limits its use to guardrails and compliance checks, when its real value is as general-purpose platform infrastructure: auto-injecting sidecars, generating default NetworkPolicies, enforcing resource quotas, and standardizing labels across every team's manifests without each team having to remember to do it manually. This is a practical distinction for platform and DevOps teams making tooling decisions in 2026, a year in which policy-as-code has become close to table stakes for any multi-tenant Kubernetes cluster. If Kyverno sits solely under a security team's purview, adoption tends to stall at "block bad things," and platform teams miss out on using the same engine to reduce toil around config generation and consistency, work that would otherwise require custom operators or repeated Helm chart boilerplate across every service. The piece reflects a broader trend CNCF has tracked through 2026: as policy engines like Kyverno, a graduated CNCF project, and OPA/Gatekeeper mature, the debate has shifted from "which policy language" to "which team owns this and what is it actually for." For engineering leaders evaluating or already running Kyverno, the practical takeaway is to explicitly scope it as platform infrastructure with security as one consumer among several, rather than the reverse, before the next budget or roadmap cycle locks in ownership and use cases for the tool.