Extending Kubernetes policy enforcement to runtime security for AI workloads

Nirmata created Kyverno and donated it to the CNCF in 2020. Kyverno is now a graduated CNCF project, widely used for enforcing and automating configuration security on Kubernetes. But admission control answers one question: does this spec look right? It cannot answer the question that matters once the pod is running: is this workload doing what its spec says it should?

With autonomous AI agents and non-deterministic LLM-enabled applications, that gap is where the interesting incidents live.

The runtime gap admission control was never built to close

The failure scenarios are familiar to anyone operating agents:

• A container with an innocuous-looking image pulls a second-stage payload after startup.
• A sidecar with network access nobody scoped tightly enough starts talking to a destination no one approved.
• A process no configuration policy anticipated executes — because the policy only ever described the container's declared behavior, not its runtime one.

One approach is kernel-level runtime enforcement: security decisions applied as workloads execute. Nirmata Runtime for Kyverno is an open-source implementation of this, using eBPF and Linux Security Modules (LSM) to extend policy enforcement beyond admission control.

Below the workload, not beside it

The design premise is simple: any control that runs beside a workload — a sidecar, an agent, a userspace proxy — is something the workload's own compromise can see, stall, or step around. A control that runs below it, in the kernel, enforcing at the same instruction as the syscall it's gating, isn't in that position. The workload doesn't get a vote.

Concretely, Nirmata Runtime attaches BPF-LSM programs directly to bprm_check_security and file_open, and cgroup-scoped eBPF programs to the egress path, per pod. Five behaviors are decided in-kernel, synchronously with the operation they gate:

• exec — deny process execution by resolved kernel path
• open — deny file access by resolved kernel path
• network — deny egress by destination
• protocol — deny by the application protocol actually spoken on the wire, independent of destination port (a reverse shell dressed up as HTTPS on 443 doesn't get a pass just because the port looks right)
• dns — observe and report, without blocking — DNS denial has failure modes worse than the traffic it would stop

A blocked exec returns -EPERM before the process runs. A blocked connection never completes. There's no window between "decision" and "enforcement" for a compromised workload to race.

Reusing Kubernetes policy concepts

If you already write Kyverno policies for admission, you know the policy language: CEL. RuntimePolicy targets workloads the same way — podSelector/namespaceSelector — and expresses allow/deny logic per behavior, including expressions that pull live values from a ConfigMap or an HTTP source on a refresh interval. Admission and runtime become one continuous policy story instead of two syntaxes glued together with tribal knowledge about which one to check first.

Every policy ships in monitor mode by default. You watch what it would deny — including a WouldDeny counterfactual signal — before flipping it to enforce. Nothing goes into blocking mode silently. It also reuses the same reporting APIs (OpenReports) and will add fine-grained exceptions similar to Kyverno.

Why this matters for AI agents

A coding agent, an MCP server, an autonomous pipeline step — these are pods too. But agents raise a question admission control was never built to answer: an agent's behavior isn't fully known at deployment time, because part of what it does is generated by a model at runtime. You can review the image; you can't review a decision the agent hasn't made yet.

For AI workloads with dynamically determined behavior, kernel-level enforcement adds a layer of control that operates independently of application-level safeguards — complementing network policies, admission controls, and application-level guardrails. If an agent's runtime is compromised (prompt injection, supply-chain dependency, a tool acting outside its bounds), the kernel controls still apply the policy you declared, no matter what the model decides next.

Bottom line

The pattern is compelling: policy expressed once, in a language operators already know, enforced where a compromised workload can't neutralize it. Admission control stays for what it's good at; in-kernel runtime enforcement covers the behavior admission never sees. That's exactly the kind of defense-in-depth AI workloads need.