Every enterprise AI conversation this year ends in the same place. A team has an agent that works. It writes code, calls internal APIs, fixes its own mistakes. Then someone asks what happens when 1,000 of these run across the company, and the room goes quiet.
That is the problem teams building agentic systems kept raising. Those teams weren’t necessarily blocked on model quality or inference throughput — they were blocked on a question nobody’s stack could answer cleanly: How do you let an agent execute code against real systems and still account for exactly what it 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. Every customer we talked to was solving this in isolation, ineffectively, and through fragmented approaches. Security for agents has to be a default of the platform they run on, not something each team rebuilds with an ad-hoc stack. That’s what Red Hat is encoding into Red Hat AI with OpenShell — an open source project and a secure agent runtime that is also part of the NVIDIA Open Agent Safety Platform.
Why OpenShell
Alongside NVIDIA and the open source OpenShell community, Red Hat is building the security layer that lets enterprises benefit from autonomous agents without giving up control. This is infrastructure the industry needs, and it’s better built in the open, where trust boundaries can be inspected and challenged by everyone relying on them.
OpenShell puts enforcement directly in the environment rather than relying solely on the model. Prompt-level guardrails matter, but a model that has been talked into misbehaving still holds whatever credentials you gave it. OpenShell governs how an agent executes, what it can see and do, and where inference goes. It is an infrastructure policy layer underneath whatever the agent happens to be. It delivers agent sandboxes built for long-running workloads, a policy engine that evaluates filesystem, network, and process access, and a gateway that checks every action before it reaches the host.
It doesn’t make the agent helpless, either. When an agent hits a constraint, it can reason about the roadblock and propose a policy change. A human keeps the approval.
Red Hat is invested in OpenShell for the long term, contributing upstream as maintainers alongside NVIDIA and the broader community because this is the layer that matters right now.
How It Runs
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 process-aware. OpenShell identifies the specific binary making each outbound connection and verifies its SHA-256 hash before evaluating the rule, so a policy can permit the agent runtime to reach one endpoint while nothing else in the sandbox can.
Credentials live outside the agent’s workload and are injected only at the network boundary. A compromised agent holds nothing worth exfiltrating. Blocked connections surface as structured Open Cybersecurity Schema Framework (OCSF) denials rather than silent failures, which is what makes them useful to a security team.
One pattern Red Hat actively advocates for, validated across various agent archetypes, is separating the thinking from the 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 enforces that split rather than trusting the agent. Today that answers a data residency requirement, but it is likely where agent security ends up more broadly.
What Was Validated
The goal was to answer: what does a secure agent deployment actually look like, regardless of which harness or framework a team picks? Teams sandbox agents in one of three ways — the whole agent, the execution environment, or only the generated code. A runtime that covers only one of them pushes the problem somewhere else. Red Hat validated OpenShell’s enforcement layer across all three, including agents built on different frameworks and running on both Podman and Red Hat OpenShift.
That validation work produced reference architectures for secure agentic workspaces — patterns for how agents handling sensitive workloads can run most securely. The first is NVIDIA’s Secure Agent Workspace reference design. Each user gets a dedicated workspace virtual machine with OpenShell sandboxing the agent execution boundary, enterprise single sign-on (SSO), GitOps-managed policy, and no shared agent process space.
The reference architecture is available as a validated pattern, and feedback is welcome as it continues to evolve.
Where This Goes Next
Red Hat is actively collaborating with NVIDIA and the community to integrate OpenShell into Red Hat AI as a native platform capability, so that agent security becomes a default rather than an assembly exercise.
A practical first step is auditing what your agents can reach today — credentials, databases, and internal services. The list is always longer than expected. The OpenShell documentation and the OpenShell repository are the places to go deeper.
