Beyond the Sandbox: The Battle for Kernel-Level Agent Security

For most of the past year, the conversation about securing AI agents has been a conversation about language. You write a system prompt that tells the model not to read files it should not read, you bolt on an output filter, and you hope the model cooperates. These are semantic controls. They work only if the model understands the rule and decides to obey it. Red Hat’s security team put the failure mode in one sentence this month: guardrails built at the model layer “can be reasoned around by the same model they’re protecting against.”

The alternative is to stop asking the model for permission. Enforce the boundary in the Linux kernel itself, with primitives like Landlock, seccomp, and network namespaces, so a compromised agent physically cannot open a file or a socket it was never granted. The difference is the one that matters in a compliance review. A prompt filter gets you to “the agent probably did not touch that file.” Kernel enforcement gets you to “the agent could not have touched that file.”

That shift from semantic to deterministic enforcement stopped being a research topic in early September. Three vendors shipped three different versions of the same answer between September 1 and September 8, and a wider story moved in behind them.

The week it became a product

On September 1, CrowdStrike launched Falcon Guardian at Fal.Con 2026, a product it is positioning as a new category called AI Detection and Response. The pitch is that the endpoint, not the model or the sandbox, is where an agent reasons and acts, so the endpoint should be the enforcement point. Falcon Guardian fuses agent activity with endpoint telemetry and claims to detect more than 200 prompt-injection techniques.

On September 7, Stacklok released ToolHive under Apache 2.0, an open source way to run any MCP server inside its own container with a minimal permission file and no local credentials attached.

On September 8, Red Hat shipped OpenShift AI 3.5 with OpenShell agent sandboxing as a Developer Preview. OpenShell is the interesting one. It enforces filesystem, syscall, and network boundaries in the kernel using Landlock, seccomp filters, and network namespace isolation.

OpenShell is not Red Hat’s. It is an NVIDIA-led, Apache-2.0 project backed by NVIDIA, Red Hat, Docker, GitHub, SAP, Google, and Dell. Red Hat packages it inside OpenShift AI. That matters, because it turns a technical thesis, kernel-level sandboxing, into something an enterprise platform ships.

What the kernel enforces, and what it does not

The word “sandbox” has been doing too much work in this conversation, and it is worth defining terms before I go further. There are two primitives being sold under the same name.

The first isolates a whole workload from the host and from other workloads. That is the gVisor, Kata, and lightweight-VM family, and it is what I wrote about in Caging the Agents. A compromised agent cannot reach the host, but it can still read any file inside its own container and open any network connection. A pod-level boundary cannot tell the difference between node and curl running in the same container, as Red Hat’s six-layer writeup puts it.

Process-level kernel enforcement is the newer thing. Landlock is a Linux security module that locks a process to specific filesystem paths at the moment the sandbox is created. seccomp restricts which syscalls the process can make, which is how it blocks privilege escalation. Network namespaces constrain what the process can reach on the network. All three are enforced by the kernel. The OS enforces the boundary, not the agent’s own code, so the agent does not get a vote.

Red Hat frames this as the answer to a specific failure. A traditional service account has a fixed permission set. An agent has a conversational interface that “can convince itself (or be convinced) to take actions its operators never anticipated.” The problem is architectural, not attitudinal.

The policy advisor is the part worth paying attention to

The kernel layer is important, but it is also the least novel part of OpenShell. Landlock and seccomp have existed for years. The novel part is what sits on top: a policy engine that treats the agent’s permission set as code, and a mechanism for the agent to ask for more.

Every OpenShell sandbox starts deny-by-default on egress. When an agent tries to reach a denied connection, OpenShell returns a structured 403 that tells the agent exactly which rule is missing and how to propose an addRule. The developer approves from outside the sandbox. For low-risk expansions there is an auto-approval mode that runs a formal prover first, with checks for things like credential reach expansion and capability expansion, before the rule hot-reloads. The governance machinery, Red Hat writes, does not trust the model’s judgment about whether its own access expansion is safe.

That inverts the usual failure. The agent is the one asking for permission, and it asks in a structured format, and the approval is a reviewable rule change rather than a shrug. The structured rule is the approval contract. The agent’s reasoning about why it needs the access is context, not authorization.

This is the concrete answer to the over-permissioning problem I kept circling in Certifying the Loop. OWASP’s fix for Excessive Agency is complete mediation, authorization in logic rather than in the model. OpenShell’s policy advisor is a running implementation of that. The agent proposes, the policy engine and a human approve, and the kernel enforces.

The endpoint disagrees

CrowdStrike is making the opposite bet. Its framing is that “the endpoint is where they reason, plan, and execute,” and that only runtime enforcement stops what is going wrong. Governance alone, it argues, cannot stop an agent already in motion. “AI hasn’t changed the attack, it has changed its speed.”

There is a real point in there, and it is the point I made in the circuit breaker post: detection after the fact is not intervention. Kernel enforcement prevents an agent from reaching a resource at all. What it does not do is stop an agent that is doing something bad with access it was legitimately given. A sandbox will not catch an agent exfiltrating data over a connection it was allowed to open. That is the gap CrowdStrike is aiming at, and it is a real gap.

I want to hold both claims at arm’s length. CrowdStrike’s numbers, 99 percent detection efficacy at under 30 milliseconds of latency, come from its own internal benchmarks, footnoted in its own press release, and no independent party has validated them. Red Hat’s kernel layer is a Developer Preview, which Red Hat itself calls “the 1st step.” These are product claims from launches that are days old. The category is real. The specific numbers are marketing until someone independent checks them.

Five vendors, one stack

Wrapped around the kernel-versus-endpoint argument is a market story that is bigger than either of them. In a two-week window, Broadcom, Citrix, CrowdStrike, ServiceNow, and Genesys all shipped some version of the same three-layer stack: connectivity through MCP, security and governance, and observability. Forkast’s read is that this was not coordinated, just “a clear signal of structural convergence.” The telling detail is that the vendors are bundling governance into existing platforms rather than selling it as a standalone product, which reads as a land grab for the gatekeeper position in every enterprise agent deployment.

The demand side explains the timing. Red Hat counts 77 percent of organizations already running agents in production, with shadow AI incidents costing on average $670,000 more than standard security incidents. Gartner has 60 percent of generative-AI proofs-of-concept abandoned in 2024, primarily over governance. Nobody is trying to monetize a single layer. They are trying to control the whole stack, and governance is where the money sits because governance is why deployments stall.

The audit trail regulators ask for

The compliance payoff is where kernel enforcement stops being a security argument and becomes a business one. OpenShell emits every network connection, file access, syscall, and HTTP request as a structured event in OCSF v1.7, the format Splunk, QRadar, and Azure Sentinel consume natively. Red Hat ties this to Article 14 of the EU AI Act, the human-oversight and traceability requirement.

I keep coming back to the distinction between this and operational observability. Dashboards tell you what your agents are doing. An audit trail in a format a regulator’s tooling already understands is what you hand over when someone asks you to prove it. And the proof is different in kind when the boundary is kernel-enforced. “Probably did not” is an opinion. “Could not have” is a fact you can demonstrate.

What I am not claiming

A few boundaries before the bottom line.

Kernel enforcement is one layer, not the answer. Red Hat’s fuller six-layer framework, published in May and updated in July, starts from the assumption that the agent will be compromised, and layers hardened platform, runtime isolation, process sandboxing, conversational guardrails, red teaming, and identity on top of each other. Its own line is that no single control is sufficient. The reason it lists so many layers is the same reason this is hard: the framework documents a VirusTotal scan that found 314 malicious skills from a single publisher on the OpenClaw marketplace whose entire payload was natural-language instructions. No code to hash-check, nothing for a malware scanner to flag. Semantic attacks are why you cannot replace the guardrails, only supplement them.

There is also a stronger counter-thesis I should name. The Sandlock and Execute-Only Agents research argues the real fix is architectural: never let untrusted data reach the model’s context at all, by splitting the planner that touches the network from the executor that touches data and joining them with a kernel pipe. On that view, sandboxing a model that is reading untrusted data is a mitigation, not a fix. I think that is a fair critique, and it is the strongest one against everything in this post.

And the maturity caveats hold. OpenShell is a Developer Preview, with an operator, SPIFFE identity, and declarative deployment still to come. ToolHive’s own authors are explicit that containerization is the easy half and wiring identity and telemetry is a second project. No independent benchmark yet shows that kernel-level enforcement alone stops prompt injection in the wild, and every vendor in this story has something to sell.

Bottom line

Agent security is splitting into two layers. The semantic layer, prompts and filters, asks a model not to misbehave. The deterministic layer, Landlock and seccomp and network namespaces, makes misbehavior physically impossible for the parts of the system the kernel controls. The second layer went from research demos to shipped product between September 1 and September 8, and the vendors are now arguing about where it lives, in the kernel or on the endpoint, while all of them bundle governance into the same three-layer stack.

For the people actually deploying agents, the practical read is the one I have been circling across this whole series. You cannot get “could not have” from a prompt. You get it from an enforcement layer the model does not get to negotiate with. The parts you can build with the operating system you already run are worth building now, because the vendors are still arguing about who owns the rest.

Sources

1. Beyond container boundaries: Kernel-level agent security in Red Hat OpenShift AI 3.5 — Red Hat (September 8, 2026)
2. ToolHive: The open-source way to run any MCP server securely — Help Net Security (September 7, 2026)
3. Five Enterprise Vendors Just Shipped the Same Three-Layer Agent Infrastructure Stack — Forkast
4. How Autonomous AI Agents Become Secure by Design With NVIDIA OpenShell — NVIDIA Blog
5. CrowdStrike Unveils Falcon Guardian to Secure AI Agents Where They Execute — CrowdStrike press release (September 1, 2026)
6. Overview of NVIDIA OpenShell — NVIDIA docs
7. Every layer counts: Defense in depth for AI agents with Red Hat AI — Red Hat Developer (May 14, 2026)
8. Sandlock: Confining AI Agent Code with Unprivileged Linux Primitives — arXiv
9. One Pipe, Two Sandboxes, Zero Prompt Injection — Multikernel Technologies