KubeCon + CloudNativeCon North America 2026 Recap
At KubeCon + CloudNativeCon North America 2026 in Salt Lake City, platform engineers from AT&T and Kinexys by J.P. Morgan showed how they run Kyverno in production. The Kyverno maintainers laid out the move to CEL policy types, and KyvernoCon showed Kyverno deciding what AI agents can do at the gateway. Here is what we saw.
Customer stories: Kyverno in production
Two of the week’s Kyverno sessions were led by customers telling their own stories.
AT&T: a valid signature is not a deployment approval
Chad Swenson, Senior Principal Software Engineer at AT&T, and Sagar Kundral, Solutions Architect at Nirmata, presented “Signed, Sealed, Denied: Attestation-Driven Admission with Kyverno + CEL at AT&T”.
Chad’s point was simple. A signed image tells you who built it and how. It does not tell you whether it may run in a particular environment. AT&T uses a Kyverno ImageValidatingPolicy written in CEL to verify the signature and the GitHub artifact attestations, then applies the rules for the destination. The same image digest can be admitted to development and denied in production because it has no signed SBOM, or fewer than two approving code reviews.
There was a nice open source moment in the talk too. AT&T needed to verify images signed with GitHub’s private Sigstore instance, which Kyverno didn’t support. Chad raised it with Jim at last year’s KubeCon + CloudNativeCon, and Jim wrote the fix himself (kyverno/kyverno#16666). It shipped in Kyverno 1.19.
Sagar closed with a benchmark run on one laptop, where only the Kyverno version changed between runs:
| Metric | Kyverno 1.18.2 | Kyverno 1.19.1 | main (1.20-dev) |
|---|---|---|---|
| Admission latency p50 / p99 | 990 / 1170 ms | 312 / 333 ms | 96 / 107 ms |
| Admissions per second | 1.0 | 3.2 | 10.4 |
| Registry calls per admission | 14 | 10 | 3 |
The milliseconds depend on the machine. In this single-laptop benchmark, registry calls per admission dropped from 14 to 3. Call counts in your clusters will vary with your images, verification policies and cache state.
Kinexys by J.P. Morgan: make the right way the easy way
Justin Munoz, Principal Software Engineer at Kinexys by J.P. Morgan, joined Jim for “The Next Generation of Kyverno: Unified Policy as Code at Scale”. His small platform team runs an EKS-based Kubernetes platform with a Git-driven delivery model, and uses Kyverno for four jobs:
- a namespace baseline that catches common misconfigurations and sets safe defaults
- restarting workloads automatically when their certificates are renewed
- blocking risky RBAC grants on
nodes/proxy - a change management gate that only lets Argo CD sync inside an approved change window
Every policy ships through Git and Argo CD like any app change, and every one starts in Audit mode. His advice for day one: “The denial message is the user interface.” Developers meet policy through its error message, so it should say what to change and why.
What’s next for Kyverno: CEL and Kyverno 1.20
In the first half of the same session, Jim covered Kyverno’s biggest architectural change so far. Kubernetes adopted CEL for its native ValidatingAdmissionPolicy and MutatingAdmissionPolicy, and Kyverno now uses the same language. Its CEL policy types (ValidatingPolicy, MutatingPolicy, GeneratingPolicy, DeletingPolicy and ImageValidatingPolicy) have been stable since v1.17.
The legacy policy types are on their way out:
| Version | What happens to ClusterPolicy and ClusterCleanupPolicy |
|---|---|
| v1.19 | Last release that processes them |
| v1.20 (released Nov 12) | The CRDs are still served, so nothing is deleted and rollback stays clean, but the policies are no longer processed |
| v1.21 | The CRDs are removed |
If you are still on ClusterPolicy, start now. The Kyverno docs have a guide for converting each rule type, a JMESPath-to-CEL guide and more than 200 sample policies, and we walked through the process in Kyverno policy migration to CEL-based policies. Jim’s tip: load the guides into your AI coding tool as a skill file and let it do the first pass.
Kyverno 1.20, released on November 12, also brings kyverno apply --explain to show why the engine made a decision, OCI packaging for policy sets, and policy exceptions with expiry dates and compensating controls. For image verification it builds on the private Sigstore fix AT&T needed with expanded support for private Sigstore deployments and GitHub attestations. It carries forward the fixes for the 26 security advisories that shipped in 1.19.2.
The roadmap after that includes a unified CLI with kyverno serve, a Rust SDK, Cedar conditional authorization, and tooling that helps AI assistants write and test policies.
KyvernoCon: deciding what AI agents can do
KyvernoCon took over the Cloud Native Theater in Hall 5 on Tuesday afternoon. Cortney Nickerson and Jim opened the event, and every talk that followed was about governing AI:
| Time (MST) | Talk | Speakers |
|---|---|---|
| 3:15 PM | After Admission: Kernel Enforcement for Agents Kyverno Let In | Sal Kimmich |
| 3:40 PM | Who’s Governing the GPU Lane? Policy as Code for AI Inference Traffic in Kubernetes | Ciara Stacke, Alessandro Fael Garcia |
| 4:05 PM | Agentic Ops: Building Guardrails for Autonomous AI with Policy-as-Code | Pavan Madduri |
| 4:30 PM | Integrating Envoy AI Gateway and Kyverno Authz for Realtime Governance of LLM and MCP Traffic | Jim Bugwadia, Deepak Goel |
To close the day, Deepak Goel, CTO for Cloud Native at Nutanix, and Jim presented Agent Router with Kyverno Authz. Agent Router (formerly Envoy AI Gateway) gives agents one API for models and one MCP endpoint for tools. Kyverno Authz sits behind it and decides on every request, using live context such as the user’s current Kubernetes permissions. A gateway alone can’t make that call, as we explained in MCP gateway vs policy enforcement.
In the live demo, they removed one user’s RoleBinding. Her agent’s tool list dropped from five tools to four, and when the agent called the missing tool anyway, the request was denied before it reached the backend. Restoring the RoleBinding brought the tool back, with the same token and the same session.
The Kyverno lightning talk
Jim’s project lightning talk on Monday asked a fair question: if Kubernetes now has native CEL policies, why do platform teams still need Kyverno? Native policies handle simple checks on a single request at admission time. Platform teams also need context from other resources, generated and synced resources, image verification, background scans, reports, exceptions, and the same policies applied to Terraform, Dockerfiles, HTTP, MCP and LLM traffic.
Kyverno ContribFest
On Wednesday, Jim, Cortney Nickerson and Saurabh Garg led the Kyverno ContribFest, “Building the Future of Unified Policy-as-Code with Kyverno”. New contributors got a hands-on session with the maintainers, working through issues tagged for the event in the kyverno, policies and website repositories.
At Booth 278: AIControls, live
All week, the team at Booth 278 ran live demos of AIControls, which lets teams decide what AI agents can do in Kubernetes and prove what they did. The booth stayed busy, and two topics came up again and again.
The first was AIControls itself. Visitors wanted to see how it works for the whole team, from the platform engineers who set the policies to everyone the policies protect. Developers, security teams and engineering leaders each asked how it would fit their part of the work.
The second was return on investment. Many of the people who stopped by were engineering leaders and VPs, and their question was direct: what does AI agent governance pay back? Our AI ROI for Engineering report covers that question.
Kyverno users had their own list of questions, mostly about what’s new: the CEL policy types, the new 1.20 release and how to plan their migration. Thanks to everyone who stopped by the booth and the Kyverno kiosk in the Project Pavilion.
Three takeaways
- Signing is evidence. Admission is the decision. Verify the evidence, apply the destination’s rules, and keep a record of why.
- Plan your CEL migration now. Kyverno 1.20 no longer processes the legacy policy types.
- AI agents need deterministic guardrails. A policy engine that checks every request puts a fixed limit on non-deterministic behavior.
See AIControls for yourself and book a demo. New to Kyverno? Start with Kyverno OSS.
Frequently asked questions
What's new in Kyverno 1.20?
Kyverno 1.20, released on November 12, 2026, stops processing the legacy ClusterPolicy and ClusterCleanupPolicy types, though their CRDs are still served so rollback stays clean. It also adds kyverno apply --explain, OCI packaging for policy sets, exception expiry with compensating controls, and faster image verification.
Do I need to migrate from ClusterPolicy?
Yes, if you plan to upgrade. Kyverno 1.19 is the last release that processes ClusterPolicy and ClusterCleanupPolicy, and 1.21 removes their CRDs. The Kyverno docs have a migration guide for each rule type, a JMESPath-to-CEL guide and more than 200 sample policies written in CEL.
Where can I watch the Kyverno talks from KubeCon + CloudNativeCon North America 2026?
The CNCF publishes KubeCon + CloudNativeCon session recordings on its YouTube channel, usually within a few weeks of the event. We'll add links to this post as the Kyverno sessions, the KyvernoCon talks and the project lightning talk go live.
What is Kyverno Authz?
Kyverno Authz runs Kyverno's CEL policies as an Envoy external authorization service. It decides on each HTTP, MCP or model request before it reaches the backend, and can use live context such as a Kubernetes SubjectAccessReview to check the caller's current permissions.