Wiki · Concept · Last reviewed June 25, 2026

Kyverno

Kyverno is a cloud-native policy engine, originally built for Kubernetes, that lets platform teams manage policy as Kubernetes-style resources.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: Kyverno, Kubernetes, policy-as-code, admission control, AI governance

Definition

Kyverno is a cloud-native policy engine. Its documentation says it was originally built for Kubernetes and can now also be used outside Kubernetes clusters as a unified policy language. The project repository describes Kyverno as a Kubernetes-native policy engine for platform engineering teams and says it supports security, compliance, automation, and governance through policy-as-code.

The Cloud Native Computing Foundation announced Kyverno's graduation on March 24, 2026. CNCF's announcement describes a project that began as a Kubernetes-native admission controller and has expanded into a broader policy engine usable through admission control, CLI workflows, container images, and software development kits. That makes Kyverno a governance tool for infrastructure, not a model evaluator.

How It Works

Kyverno policies can validate, mutate, generate, and clean up resources. Its repository also describes image-signature verification for software supply-chain security and operation with familiar Kubernetes workflows such as kubectl, Kustomize, and Git. The practical distinction from OPA Gatekeeper is language and ergonomics: Kyverno policies are Kubernetes-style resources rather than Rego templates.

Kubernetes admission control is the mechanism that gives this kind of policy engine force inside a cluster. Kubernetes documentation describes admission controllers as request checks that run after authentication and authorization and before resource persistence. Its dynamic admission-control documentation describes admission webhooks as HTTP callbacks that can validate or mutate API-server requests. Kyverno uses that admission layer for cluster enforcement and can also perform background scans.

Kyverno's reporting documentation says it uses the policy-report format associated with the Kubernetes Policy working group. Those reports matter because they turn policy evaluation into an inspectable record: which rule passed, which failed, what resource was involved, and where remediation should focus. Kyverno also documents image validation policies, including examples that verify signatures and attestations for container images.

Agent Context

For AI and agent systems, Kyverno's relevance is deployment governance. Model servers, browser workers, code sandboxes, vector databases, tool APIs, and batch evaluators often become Kubernetes resources. A deployment agent can create those resources quickly, and an ordinary CI pipeline can propagate mistakes just as fast. Kyverno gives the cluster a policy surface before those resources become running infrastructure.

Useful local policies might require owner labels, block privileged containers, reject mutable image tags, require resource limits, require approved namespaces for tool servers, or verify image evidence before admission. These are infrastructure rules. Passing them should not be described as proof that a model is aligned, a tool is safe, or a workflow is socially acceptable. It means the submitted resource met the configured policy.

Governance Use

A governance-grade Kyverno record should preserve the policy name, rule, policy version, resource kind, namespace, service account, admission operation, background-scan status, enforcement mode, result, message, exception path, and remediation owner. For image policies, it should also preserve image digest, registry, attestation type, verifier configuration, signer or identity constraints, and the evidence timestamp.

Kyverno should also be governed as code. Policies should be versioned, reviewed, tested before cluster rollout, staged from audit to enforce where appropriate, and paired with operational owners. A policy engine can become its own outage mechanism if a broad rule is wrong, too strict, or rolled out without a rollback path.

Limits

Kyverno does not inspect model reasoning, prompts, generated outputs, labor conditions, user consent, or downstream human effects. It controls resource configuration and related evidence at policy evaluation points. Runtime behavior still needs workload identity, network policy, logging, sandboxing, human review, rate limits, and incident response.

Admission control also has structural limits. Kubernetes documentation distinguishes admission from authentication and authorization and notes that admission controllers act on resource-modifying operations rather than ordinary reads. A system can bypass policy through privileged paths, excluded namespaces, stale exceptions, separate clusters, or non-Kubernetes deployment routes. Kyverno is a strong gate only where it is actually installed, scoped, and monitored.

Source Discipline

Claims about Kyverno should cite Kyverno documentation, the Kyverno repository, CNCF project communications, and Kubernetes admission-control documentation. Claims about AI should be labeled as deployment inferences: Kyverno governs cloud-native resources, and the AI relevance follows when AI systems are deployed as those resources.

Do not collapse Kyverno into Open Policy Agent, Gatekeeper, built-in Kubernetes ValidatingAdmissionPolicy, Ratify, or general CI scanning. These tools overlap in purpose, but they differ in policy language, enforcement point, evidence model, and audit record.

Spiralist Reading

Spiralism reads Kyverno as a quiet institutional brake: not a sermon about safety, but a set of resource-shaped refusals written where automation has to pass.

That is its value for agent infrastructure. The cluster should not have to believe a deployment story. It can ask for labels, limits, signatures, namespaces, and records before the story becomes a process with credentials.

Sources

Return to Wiki