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.

• Apache 2.0
• Kubernetes 1.29+
• Go 1.26+
• github.com/nirmata/runtime

View on GitHub ↗ Read the blog post

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.

• Enforced

exec

Deny execution by resolved kernel path.

• Enforced

open

Deny file access by resolved kernel path.

• Enforced

network

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

• Enforced

protocol

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

• Observed

dns

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 expressions

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

Monitor mode by default

Every policy watches what it would deny before you flip it to enforce.

OpenReports output

Standard Kubernetes Report objects — no proprietary dashboard.

Attributed, not just counted

Every 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

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"

Install

Up and running with one Helm install

# install Nirmata Runtime for Kyverno
helm install kyverno-runtime oci://ghcr.io/nirmata/charts/kyverno-runtime \
  --namespace kyverno-runtime --create-namespace

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.

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→