Red Hat Builds OpenShell Into Red Hat AI to Secure Autonomous Agents

The problem: agents that can execute code

Red Hat says enterprise AI conversations this year keep ending at the same point. A team has a working agent that writes code, calls internal APIs and fixes its own mistakes. Then someone asks what happens when 1,000 such agents run across the company.

According to the authors, Adel Zaalouk and Younes Ben Brahim, the teams they spoke with were not blocked by model quality or inference throughput. They were stuck on a question no stack answered cleanly: how can an agent execute code against real systems while the company still accounts for exactly what it touched and who approved it?

The post draws a clear line between text and action. When an agent only generates text, the worst outcome is a bad answer. When it can execute, the worst outcome is a deleted production database. Red Hat says every customer it talked to was solving this in isolation and through fragmented approaches.

How OpenShell works

OpenShell is an open source project and a secure agent runtime. Red Hat says it is also part of the NVIDIA Open Agent Safety Platform, launched on the day of the post. Red Hat is contributing upstream as a maintainer alongside NVIDIA and the broader community.

The approach puts enforcement in the environment instead of relying only on the model. Red Hat argues that prompt-level guardrails matter, but a model that has been talked into misbehaving still holds whatever credentials it was given. According to the post, OpenShell governs how an agent executes, what it can see and do, and where inference goes.

• Sandboxes: built for long-running workloads, with each agent, session, or both running as its own execution environment.
• Enforcement layers: Landlock, seccomp, user and network namespace isolation, and L7 inspection.
• Policy engine: evaluates filesystem, network and process access, while a gateway checks every action before it reaches the host.
• Process-aware policy: OpenShell identifies the binary making each outbound connection and verifies its SHA-256 hash before evaluating the rule.
• Credentials: kept outside the agent's workload and injected only at the network boundary.
• Denials: blocked connections appear as structured Open Cybersecurity Schema Framework (OCSF) denials rather than silent failures.

Agents are not left helpless. When one hits a constraint, it can reason about the roadblock and propose a policy change, but a human keeps the approval.

Separating thinking from execution

Red Hat says it advocates, and has been validating across various agent archetypes, a split between thinking and execution. Reasoning and orchestration stay with a model provider. Code execution and file access happen inside a sandbox on infrastructure the customer controls. The platform would enforce that split rather than trusting the agent. Red Hat says this answers a data residency requirement today and expects agent security to move in this direction more broadly.

Validation and reference architecture

Red Hat says it set out earlier this year to define what a secure agent deployment looks like regardless of harness or framework. It observed that teams sandbox agents in one of three ways: the whole agent, the execution environment, or only the generated code. A runtime covering only one of these pushes the problem elsewhere.

The company says it validated OpenShell's enforcement layer across all three approaches, including agents built on different frameworks and running on both Podman and Red Hat OpenShift. That work produced reference architectures for secure agentic workspaces.

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, enterprise single sign-on (SSO), GitOps-managed policy and no shared agent process space. It is available as a validated pattern, and Red Hat says it is looking for feedback.

What it means for enterprise teams

Red Hat says it is collaborating with NVIDIA and the community to integrate OpenShell into Red Hat AI as a native platform capability. The post gives no timeline for that integration.

For teams running agents now, the authors offer a practical first step: audit what your agents can reach today, including credentials, databases and internal services. In their words, the list is always longer than expected. The OpenShell documentation and repository are the suggested starting points for going further.