Red Hat said on September 28 that it is contributing to OpenShell, an open source secure agent runtime that the company describes as part of the NVIDIA Open Agent Safety Platform launched the same day. In a blog post, two Red Hat product leads said the project is intended to move AI agent security from prompt-level guardrails into the infrastructure the agents run on.
The problem Red Hat says it kept hearing
Principal product manager Adel Zaalouk and principal product marketing manager Younes Ben Brahim wrote that teams building agentic systems were not blocked on model quality or inference throughput, but on accounting for what an agent touched and who approved it.
"When an agent can only generate text, the worst outcome is a bad answer. When an agent can execute, the worst outcome is a deleted production database," they wrote, adding that every customer they talked to was solving the problem in isolation and through fragmented approaches.
Red Hat said security for agents should be a default of the platform agents run on, and that it is encoding this into Red Hat AI with OpenShell alongside NVIDIA and the OpenShell community.
How Red Hat says OpenShell works
According to the post, OpenShell puts enforcement in the environment rather than relying solely on the model, because a model that has been talked into misbehaving still holds whatever credentials it was given. A policy engine evaluates filesystem, network and process access, and a gateway checks every action before it reaches the host.
Red Hat said OpenShell runs each agent, session, or both as its own execution environment with multiple enforcement layers, including Landlock, seccomp, user and network namespace isolation, and L7 inspection. Policy is described as process-aware: OpenShell identifies the binary making each outbound connection and verifies its SHA-256 hash before evaluating the rule.
Credentials, the company said, live outside the agent's workload and are injected only at the network boundary, so "A compromised agent holds nothing worth exfiltrating." Blocked connections surface as structured Open Cybersecurity Schema Framework (OCSF) denials rather than silent failures. When an agent hits a constraint, Red Hat said it can reason about the roadblock and propose a policy change, with a human keeping the approval.
Validation and reference architectures
Red Hat said it observed that teams sandbox agents in one of three ways — the whole agent, the execution environment, or only the generated code — and that it validated OpenShell's enforcement layer across all three, including agents built on different frameworks and running on both Podman and Red Hat OpenShift.
That work led to reference architectures for secure agentic workspaces, the first being NVIDIA's Secure Agent Workspace reference design, in which each user gets a dedicated workspace virtual machine with OpenShell sandboxing the agent execution boundary, enterprise single sign-on, GitOps-managed policy and no shared agent process space. Red Hat said the reference architecture is available as a validated pattern and that it is seeking feedback.
The company also said it advocates separating reasoning and orchestration, which stay with a model provider, from code execution and file access, which happen inside a sandbox on infrastructure the customer controls. Red Hat said it is collaborating with NVIDIA and the community to integrate OpenShell into Red Hat AI as a native platform capability.
What to do
- Audit what your agents can currently reach, including credentials, databases and internal services; Red Hat says the list is usually longer than teams expect.
- Consult the OpenShell documentation and repository as starting points, per Red Hat's post.
- Consider Red Hat's recommended split of keeping reasoning and orchestration with a model provider while running code execution and file access in a sandbox on infrastructure you control.
- Review the Secure Agent Workspace validated pattern and send Red Hat feedback, which the company says it is actively seeking as the reference architecture evolves.
Key facts and where they come from
- Red Hat describes OpenShell as an open source project and secure agent runtime that is part of NVIDIA's Open Agent Safety Platform, launched the day of the post.
OpenShell — an open source project and a secure agent runtime also part of the NVIDIA Open Agent Safety Platform launched today.
- OpenShell runs each agent and/or session in its own execution environment with several kernel- and network-level enforcement layers.
including Landlock, seccomp, user and network namespace isolation, and L7 inspection
- Policy enforcement is process-aware and checks binary hashes before applying network rules.
OpenShell identifies the specific binary making each outbound connection and verifies its SHA-256 hash before evaluating the rule
- Credentials are kept out of the agent workload and injected at the network boundary.
Credentials live outside the agent's workload and are injected only at the network boundary.
- Denied connections are emitted in OCSF format instead of failing silently.
Blocked connections surface as structured Open Cybersecurity Schema Framework (OCSF) denials rather than silent failures
- Red Hat says it tested the enforcement layer against all three sandboxing patterns it identified, on Podman and OpenShift.
We validated OpenShell's enforcement layer across all 3, including agents built on different frameworks and running on both Podman and Red Hat OpenShift.
- The first reference architecture is NVIDIA's Secure Agent Workspace design, giving each user a dedicated workspace VM.
The first is NVIDIA's Secure Agent Workspace reference design. Each user gets a dedicated workspace virtual machine (VM) with OpenShell sandboxing the agent execution boundary
- Agents blocked by policy can propose changes, but humans approve them.
When an agent hits a constraint, it can reason about the roadblock and propose a policy change. A human keeps the approval.