# Enforcing Security at the Kernel Level for Kubernetes Workloads
## Why Admission Control Isn’t Enough
Kubernetes has long relied on admission controllers to validate whether a pod specification looks correct before it starts. These tools check container images, resource limits, network policies, and other declared configurations to ensure workloads meet organizational standards. But there’s a critical blind spot: once a pod is up and running, is it actually doing what its specification says it should?
This gap is where many of the most interesting security incidents live today. An innocent-looking container image might download a second-stage payload shortly after startup. A sidecar with overly broad network permissions could begin communicating with an external destination that was never approved. A process might execute that no one anticipated, because the original policy only described what the container *should* do — not what it *actually* does while running.
For teams running autonomous AI agents and non-deterministic, LLM-powered applications, this problem becomes even more pronounced. These workloads make decisions at runtime that couldn’t have been fully predicted at deployment time.
## Enforcing Security from Inside the Kernel
The most effective way to close this gap is to move enforcement into the kernel itself. When a security control runs alongside a workload — as a sidecar, agent, or userspace proxy — it becomes visible to that workload. A compromised process can see, stall, or work around it. But a control that operates *below* the workload, at the same instruction level as the system calls it governs, sits in a fundamentally stronger position. The running process simply doesn’t get a say.
This is where eBPF (extended Berkeley Packet Filter) and Linux Security Modules (LSM) come in. By attaching BPF-based programs directly to key kernel functions, security decisions can be enforced synchronously — at the exact moment a syscall happens — rather than checked after the fact.
### Five Enforcement Capabilities
Kernel-level runtime enforcement can cover several critical behaviors:
– **Process execution control** — Prevent a container from running binaries that aren’t on an approved list, based on their resolved file paths in the kernel.
– **File access restriction** — Block a workload from reading sensitive files such as credential stores, SSH keys, or service account tokens.
– **Network egress filtering** — Deny outbound connections to destinations outside an approved list.
– **Protocol-level enforcement** — Identify and control the actual application protocol being spoken over the wire, not just the port. A reverse shell disguised as HTTPS traffic on port 443 doesn’t get a free pass just because the port number looks legitimate.
– **DNS observation** — Monitor and log DNS resolution activity without blocking it, since blocking DNS can cause failure modes that are worse than the traffic itself.
When a policy blocks a process from executing or a connection from completing, the decision is made and enforced in the kernel before the operation runs. There’s no window of opportunity for a compromised workload to race around the decision.
## Reusing Familiar Policy Concepts
One of the biggest barriers to adopting runtime security is adding a new tool with a new syntax and new semantics. A better approach is to extend the policy language teams already know and trust into the runtime space.
By using the same policy expression language for runtime enforcement that teams use for admission control, organizations can create a single, continuous security story. The same targeting concepts — selecting workloads by pod labels or namespace — apply to both stages. And policies can pull live values from configuration sources, updating their behavior on a schedule without requiring redeployment.
### Safe Rollout with Monitor Mode
Every runtime policy starts in **monitor mode** by default. This means the system observes what *would* be denied, recording counterfactual signals that show the impact of enforcement — without actually blocking anything. Teams can review these findings, tune their policies, and gain confidence before switching to active enforcement. Nothing goes into blocking mode silently.
## Securing AI Agent Workloads
AI agents — whether coding assistants, model servers, or autonomous pipeline steps — represent a unique security challenge. Their behavior at runtime is partially determined by model-generated decisions that couldn’t have been fully predicted during deployment. You can audit the container image, but you can’t audit a decision the agent hasn’t made yet.
Kernel-level runtime enforcement provides an additional layer of protection for these workloads that operates independently of any application-level safeguards. If an agent’s runtime environment is compromised — through prompt injection, a malicious supply-chain dependency, or an unauthorized tool call — the enforcement boundary can’t be reasoned around, argued with, or quietly disabled by the compromised process, because the enforcement isn’t running inside that process at all.
### Practical Policy Examples
With kernel-level enforcement, teams can apply fine-grained controls per agent workload:
– **Restricting model providers and endpoints** — Network and protocol policies can ensure an agent only communicates with an approved internal gateway, catching attempts to reach any other service.
– **Limiting binary and tool execution** — Execution allow-lists ensure agents can only invoke exactly the tools and helpers described in their workload contract.
– **Detecting undeclared capabilities** — Policies can identify agent CLIs, SDKs, model files, and configuration artifacts present in an image that weren’t originally intended for agent workloads.
For example, a policy for an agent pod might restrict network egress to only an internal LLM gateway and DNS resolution, allow only TLS and DNS protocols, and explicitly deny access to common credential file paths on the local filesystem. If a prompt injection attempts to exfiltrate credentials or reach an unauthorized endpoint, the kernel enforces the denial before the agent’s process can act on it.
## Contextual Observability
Security monitoring becomes far more valuable when it explains *why* something was flagged, not just *that* something happened. When a runtime policy denies an operation, the kernel encodes the decision with enough context to attribute it to the exact policy responsible.
If an event can’t be matched to a specific policy, it isn’t silently dropped — it’s counted and reported as an unattributed event, because a monitoring blind spot that looks like “nothing happened” is far worse than a visible error. Findings are surfaced as standard Kubernetes objects, so teams don’t need a proprietary dashboard to understand what their cluster is doing.
Raw observation and a readable report serve very different purposes. Without filtering, monitoring all process executions in a pod streams enormous volumes of noise — routine shell commands, health checks, and logging utilities that are part of normal operation. A filtering layer built into the policy itself can distinguish signal from noise, ensuring that reports only surface meaningful events. For instance, a policy can flag only agent CLI invocations or local inference server launches, matching on the actual name a process was invoked under rather than just the executable path.
## Looking Ahead
Runtime enforcement is one layer in a defense-in-depth strategy for securing modern Kubernetes environments. As workloads grow more complex — especially with the rise of autonomous agents and AI-powered applications — combining kernel-level runtime controls with admission policies, network segmentation, and application-level safeguards creates a more resilient security posture across every stage of the workload lifecycle.
This technology is available as an open source project, and the community is encouraged to explore the implementation, review real-world examples, contribute improvements, and share feedback.
—
## Frequently Asked Questions
**What is the difference between admission control and runtime enforcement?**
Admission control validates a workload’s specification *before* it starts running — checking things like image sources, resource limits, and network policies. Runtime enforcement operates *while* the workload is running, making security decisions at the kernel level about actual behavior: what processes execute, what files are accessed, and what network connections are made.
**Why run enforcement in the kernel instead of as a sidecar or agent?**
A sidecar or userspace proxy runs in the same process space as the workload it’s trying to protect. If that workload is compromised, it can detect, interfere with, or bypass the sidecar. Kernel-level enforcement operates below the workload, at the same instruction level as the system calls it governs. The workload has no way to see or override it.
**What is eBPF and why is it used for runtime security?**
eBPF (extended Berkeley Packet Filter) is a Linux technology that allows custom programs to run safely inside the kernel without modifying the kernel source code. For security purposes, eBPF programs can be attached to key kernel functions — like system call entry points — to make real-time decisions about what a process is allowed to do.
**Can I try these policies before enforcing them?**
Yes. Runtime policies ship in monitor mode by default, which observes and reports what *would* be denied without actually blocking any operations. This allows teams to validate policies against real workload behavior before flipping them to enforcement mode.
**How does this help secure AI agent workloads specifically?**
AI agents make runtime decisions that are partially unpredictable at deployment time — such as which tools to call or which endpoints to reach. Kernel-level enforcement applies controls that operate independently of the agent’s own logic, so even if the agent is compromised, the security boundary cannot be bypassed from inside the workload.
**Does this require any special node configuration?**
Kernel-level enforcement using eBPF programs requires a Linux kernel with eBPF support enabled. Some features, such as file access control, also require BPF-LSM support in the kernel.
—
## Conclusion
The shift from spec-time validation to runtime enforcement represents an important evolution in Kubernetes security. By moving enforcement into the kernel using eBPF and Linux Security Modules, organizations can close the gap between what a workload *claims* to do and what it *actually* does — even as those behaviors become more dynamic and unpredictable with AI-powered workloads. Combining this approach with existing admission controls, network policies, and application-level safeguards creates a layered defense that is significantly harder for an attacker to circumvent.
Thank you for reading
