Today Nirmata released an open‑source extension called Nirmata Runtime for Kyverno that moves policy enforcement from Kubernetes admission control into the kernel using eBPF and Linux Security Modules. The shift means that the same Kyverno policies can now decide whether a process may execute, a file may be opened, or network traffic may leave a pod while the workload is running, addressing the blind spot that admission checks leave for AI‑driven and other dynamic workloads.
Why Admission‑Only Checks Miss Runtime Threats
Admission controllers answer the question “does this pod spec look correct?” but they cannot verify what the workload actually does after it starts. AI agents, LLM‑enabled services, and containers that fetch secondary payloads can exhibit behavior that was not visible at deployment time. Examples from the source include a benign‑looking image that pulls a malicious second‑stage payload, a sidecar that contacts an unapproved endpoint, or a process that runs a binary not covered by the original spec. Those incidents happen at runtime, where traditional admission policies have no visibility.
How Kernel‑Level Enforcement Works
The runtime component attaches BPF‑LSM programs to the kernel hooks bprm_check_security (process execution) and file_open (file access). It also deploys cgroup‑scoped eBPF programs on the egress path to control network traffic per pod. Five distinct behaviors are evaluated synchronously:
- exec – blocks a process before it runs, returning
-EPERM. - open – blocks file reads/writes based on the resolved kernel path.
- network – blocks outbound connections before they complete.
- protocol – inspects the application protocol on the wire, denying traffic that does not match an allowed list even if the destination port is permitted.
- dns – observes DNS queries and reports them without blocking, because DNS denial can cause broader failures.
Because the decision and enforcement happen in the same kernel instruction, a compromised workload cannot race between “allowed” and “blocked” states.
Policy Model Mirrors Kyverno Admission Policies
Runtime policies reuse the Kyverno CEL language and the same selector model (podSelector, namespaceSelector). The new resource type is RuntimePolicy, which defaults to monitor mode. In this mode the system records what would have been denied, exposing a WouldDeny counterfactual metric before any enforcement is turned on. Reporting uses the existing OpenReports API, and the design plans to add fine‑grained exceptions that behave like Kyverno’s existing exception mechanism.
Practical Implications for AI and Agent Workloads
For pods that host autonomous agents, the runtime layer can enforce contracts that are impossible to verify at build time. Example controls include:
- Limiting which model provider DNS names and network destinations an agent may contact.
- Allow‑listing specific binaries or MCP servers that the agent is permitted to launch.
- Detecting the presence of credential files or other sensitive artifacts before they are accessed.
A minimal policy that enforces these constraints looks like the following:
apiVersion: runtime.nirmata.io/v1alpha1
kind: RuntimePolicy
metadata:
name: agent-gateway-only
spec:
mode: enforce
podSelector:
matchLabels:
nirmata.io/agent: "true"
behaviors:
- network:
allow:
values:
- llm-gateway.ai-platform.svc.cluster.local
- kube-dns.kube-system.svc.cluster.local
deny:
values:
- "*"
- protocol:
allow:
values:
- tls
- dns:
deny:
values:
- "*"
- open:
deny:
values:
- "/root/.aws/credentials"
- "/root/.kube/config"
- "/root/.ssh/id_rsa"
- "/var/run/secrets/kubernetes.io/serviceaccount/token"
Both the network and protocol sections use a wildcard sentinel, meaning a connection must satisfy both checks to be allowed.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Teams should start by enabling monitor mode on existing Kyverno policies to collect WouldDeny data and understand the runtime footprint of their workloads. If the observed denials align with security intent, they can transition policies to enforce mode. Deploying the runtime component requires a kernel that supports eBPF and LSM hooks, so verify node OS versions before rollout. Finally, integrate the new RuntimePolicy objects into existing CI/CD pipelines so that admission and runtime controls remain a single source of truth.
