Open Source · Apache 2.0

Detect and enforce agent runtime behavior

Open-source, kernel-level enforcement for Kubernetes — built on eBPF and BPF‑LSM, in the same CEL policy language as Kyverno.

View on GitHub ↗ Read the blog post
Apache 2.0· Kubernetes 1.29+· Go 1.26+· github.com/nirmata/runtime
Container / AI Workload
System Call Interface
Kernel-Level Enforcement
exec
open
network
protocol
dns
Kernel Layer — decides before the syscall completes

The Problem

"Does this spec look right?" isn't "is this workload behaving right?"

Admission control checks a pod's spec once, before it starts. With autonomous agents, that's not enough — part of what they do is decided at runtime.

A second-stage payload

An innocuous image pulls extra code after startup.

An unscoped sidecar

Network access nobody scoped talks to a destination no one approved.

An unanticipated exec

A process runs that no policy ever described — only its declared spec was.

Design Premise

A sidecar can be starved. A proxy can be routed around. The kernel can't.

A control beside a workload is something a compromise can see, stall, or step around. Nirmata Runtime runs below it — enforcing at the same instruction as the syscall it gates.

exec / open— BPF‑LSM programs attached to bprm_check_security and file_open
network / protocol— cgroup‑scoped eBPF on the egress path, per pod
return -EPERM; before the process runs.
No window between decision and enforcement for a compromised workload to race.

Enforcement Surface

Five behaviors, all decided in-kernel

No window between the syscall and the verdict.

exec
Enforced

Deny execution by resolved kernel path.

open
Enforced

Deny file access by resolved kernel path.

network
Enforced

Deny egress by address, CIDR, domain, or Service.

protocol
Enforced

Deny by the protocol on the wire, not the port — HTTPS-on-443 doesn't excuse a reverse shell.

dns
Observed

Report resolution without blocking — DNS denial fails worse than the traffic itself.

Policy Model

One policy language — if you write Kyverno policies, you already know this one

Same podSelector / namespaceSelector targeting, same CEL. Admission and runtime, one continuous policy story.

CEL expressionsThe Kubernetes CEL libraries Kyverno already uses, refreshable from a ConfigMap or HTTP source.

Monitor mode by defaultEvery policy watches what it would deny before you flip it to enforce.

OpenReports outputStandard Kubernetes Report objects — no proprietary dashboard.

Attributed, not just countedEvery deny is traced to the policy responsible; gaps are logged, never dropped.

AI Agents

An agent's behavior isn't fully known at deploy time

A coding agent or MCP server is a pod too. You can review the image — not the decision it hasn't made yet. If its runtime is compromised, the enforcement boundary isn't running inside that process to be argued with.

Bound model providers

dns / network block egress outside an approved list.

Restrict binaries & MCP servers

exec allow-lists close off arbitrary tool invocation.

Detect undeclared surfaces

Agent CLIs, SDKs, model files, and MCP configs nobody built for.

agent-gateway-only.yaml — a policy on an agent pod that should only reach an internal LLM gateway examples/shadow-ai → 
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"

A prompt injection can run cat ~/.aws/credentials — the kernel has already decided before the agent gets a chance to argue.

Install

Up and running with one Helm install

terminal
# install Nirmata Runtime for Kyverno
helm install kyverno-runtime oci://ghcr.io/nirmata/charts/kyverno-runtime \
  --namespace kyverno-runtime --create-namespace
View on GitHub ↗ Browse Examples
Base requirements

Linux nodes, kubectl, helm, git, K8s 1.29+.

network / protocol

cgroup v2 + BPF support on the node.

exec / open

BPF‑LSM active on the kernel.

The Full Stack

Runtime works standalone. It works best alongside Kyverno and AIControls.

One policy language, one audit trail — across admission, runtime, and the AI gateway.

Explore Kyverno OSS → Explore AIControls →

Start with open-source kernel enforcement.

Give it a ⭐ on GitHub, run it on one namespace, and watch what monitor mode finds before you enforce anything.

View on GitHub ↗ Request a Demo