kubernetessecurityPractitioner

Runtime Security for AI Workloads: Extending Kubernetes Policy Enforcement

5 min read CNCF BlogOct 15, 2026Reviewed for accuracy

Practitioner — Hands-on experience recommended

The rise of AI workloads in Kubernetes environments brings unique security challenges. Traditional admission controls are not enough to ensure that these workloads operate safely in production. Nirmata Runtime addresses this gap by providing kernel-level runtime enforcement, allowing you to define security policies that apply to workloads dynamically, based on their behavior during execution.

Nirmata Runtime utilizes eBPF and Linux Security Modules (LSM) to enforce policies at the kernel level. It attaches BPF-LSM programs to critical security checks, such as bprm_check_security and file_open, and uses cgroup-scoped eBPF programs for network egress control. You can define a RuntimePolicy that specifies behaviors to allow or deny, such as process execution, file access, and network communications. For instance, you can set a policy to deny all network egress except for specific trusted destinations. The configuration parameters include mode, which can be set to either enforce or monitor, and podSelector, which determines the pods the policy applies to.

In practice, implementing Nirmata Runtime requires careful consideration of the behaviors you want to control. You can start with monitor mode to observe events before enforcing strict policies. Be aware that defining overly restrictive policies may lead to unexpected behavior in your workloads, so testing is crucial. The current version is posted as of October 15, 2026, so keep an eye on updates that may enhance functionality or introduce new features.

Key takeaways

→Utilize Nirmata Runtime for kernel-level security enforcement in Kubernetes.
→Define `RuntimePolicy` to control behaviors like exec, open, and network egress.
→Start with monitor mode to observe workload behavior before enforcing policies.

Why it matters

In production, securing AI workloads is paramount to prevent data leaks and unauthorized access. Nirmata Runtime provides a robust mechanism to enforce security policies dynamically, reducing the risk of vulnerabilities.

Code examples

YAML

1apiVersion: runtime.nirmata.io/v1alpha1
2kind: RuntimePolicy
3metadata:
4  name: agent-gateway-only
5spec:
6  mode: enforce
7  podSelector:
8    matchLabels:
9      nirmata.io/agent: "true"
10  behaviors:
11  - network:
12      allow:
13        values:
14        - llm-gateway.ai-platform.svc.cluster.local
15        - kube-dns.kube-system.svc.cluster.local
16      deny:
17        values:
18        - "*"
19  - protocol:
20      allow:
21        values:
22        - tls
23        - dns
24      deny:
25        values:
26        - "*"
27  - open:
28      deny:
29        values:
30        - "/root/.aws/credentials"
31        - "/root/.kube/config"
32        - "/root/.ssh/id_rsa"
33        - "/var/run/secrets/kubernetes.io/serviceaccount/token"

YAML

1apiVersion: runtime.nirmata.io/v1alpha1
2kind: RuntimePolicy
3metadata:
4  name: detect-agent-cli
5spec:
6  mode: monitor
7  podSelector:
8    matchLabels:
9      app: ai-workload
10  behaviors:
11  - exec:
12      deny:
13        values: ["*"]
14  monitorFilter:
15    expressions:
16    - name: exec-events-only
17      expression: 'has(event.exec)'
18    - name: agent-cli-or-inference-server
19      expression: >-
20        event.exec.argv.exists(a, a in [
21          "claude", "codex", "gemini", "aider", "goose", "opencode", "crush",
22          "cursor-agent", "ollama", "litellm", "text-generation-launcher",
23        ]) ||
24        event.exec.argv.exists(a,
25          a.startsWith("@anthropic-ai/") ||
26          a.startsWith("@openai/") ||
27          a.startsWith("@google/gemini-cli"))

When NOT to use this

The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.

Want the complete reference?

Read official docs

Test what you just learned

Quiz questions written from this article

Take the quiz →

Linux FoundationSponsor

Industry-standard certifications built by the people behind Linux and Kubernetes. Earn the CKA — the gold standard Kubernetes administrator cert. OpsCanary readers get 30% off year-round with code OPSCANARY3.

Get CKA certified →

Runtime Security for AI Workloads: Extending Kubernetes Policy Enforcement

Key takeaways

Why it matters

Code examples

When NOT to use this

More on this topic

Navigating NIS2 and DORA Ownership in Kubernetes Teams

Guardrails, Not Gates: Rethinking Policy in Kubernetes

Security Slam 2026: Elevate Your Kubernetes Security Posture