↓ Skip to main content
  1. Security/

OpenShell

Agents Sandbox Policy Nvidia Openshift Kubernetes Seccomp
Table of Contents

OpenShell is an open-source runtime for fleets of autonomous AI agents. An agent is useful because it can read files, run commands, call APIs, and use credentials; that is also the capability profile of a compromised workload. OpenShell leaves the agent free to plan and use tools, and enforces what it may touch outside the model. Three pieces do the work: a gateway manages sandboxes and their policies, a supervisor sits outside the workload and inspects every outbound request, and the sandbox confines the process with kernel controls — Landlock on the filesystem, seccomp on system calls, and user and network namespaces — so the only network path is through the supervisor. Credentials stay outside the agent and are attached only to requests bound for an approved endpoint. Policy is written in YAML, compiled to OPA/Rego, and checked by a prover before a change is applied, so a requested permission can be shown to cross a boundary even if the agent argues that it does not. Denials come back as structured OCSF events rather than silent failures. Prompt guardrails still matter, but they are not the boundary: a model that has been talked into misbehaving keeps whatever credentials it was given unless the runtime never put them there.

Red Hat is an upstream maintainer of OpenShell, alongside NVIDIA, and is building it into Red Hat AI as the secure agent runtime rather than a control each team assembles alone. The problem Red Hat describes is onboarding: a team already has an agent that works, and nobody can say what happens when a thousand of them execute against real systems, or who approved what they touched. OpenShell is the enforcement layer under the harness. On OpenShift, Red Hat’s validated pattern is to run that sandbox inside OpenShift sandboxed containers, which is Kata Containers: OpenShell governs egress, files, and processes, and the Kata micro-VM gives the workload its own kernel. The two do not overlap. In Red Hat’s July 2026 tests on OpenShift 4.21, an exfiltration curl was policy_denied wherever OpenShell was present and leaked wherever only Kata was present; a page-cache exploit, CVE-2026-31431, escaped the OpenShell-only pod because Landlock and seccomp share the host kernel with the workload, and was contained wherever Kata was present. Only the pod with both stopped both attacks. Red Hat’s platform reading is the same split at a larger scale: OpenShift AI and Red Hat AI Inference for the model path, OpenShift for isolation, policy, and networking, RHEL as the operating system, and OpenShell as one enforcement point that can sit under a governance decision instead of inside the agent. Reasoning can stay with a model provider; code execution and file access stay in a sandbox on infrastructure the customer controls. When the agent hits a constraint it can propose a narrower policy change, and a person keeps the approval.

Relevant Red Hat blog posts
#

Related