Why Red Hat is building secure agent onboarding

Every enterprise AI conversation we’ve had 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 we kept hearing from teams building agentic systems. 

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 in isolation with an ad-hoc stack. That’s what we are encoding into Red Hat AI with OpenShell — an open source project and a secure agent runtime also part of the NVIDIA Open Agent Safety Platform launched today.

Why OpenShell

Alongside NVIDIA and the open source OpenShell community, we’re 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’s 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 evaluates filesystem, network, and process access. A gateway 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 we believe 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 1 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 we actively advocate for, and have been validating 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 will enforce that split rather than trusting the agent. Today that answers a data residency requirement, but we think it is where agent security ends up more broadly.

What we validated

Earlier this year we set out to answer "what does a secure agent deployment actually look like, regardless of which harness or framework a team picks?" We observed that teams sandbox agents in 1 of 3 ways: the whole agent, the execution environment, or only the generated code. A runtime that covers 1 of them pushes the problem somewhere else. We validated OpenShell's enforcement layer across all 3, including agents built on different frameworks and running on both Podman and Red Hat OpenShift.

That validation work led to reference architectures for secure agentic workspaces. These are 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 (VM) with OpenShell sandboxing the agent execution boundary, with enterprise single sign-on (SSO), GitOps-managed policy, and no shared agent process space. 

The reference architecture is available as a validated pattern, and we are actively looking for feedback as we continue to evolve it.

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.

Start by auditing what your agents can reach today, including credentials, databases, and internal services. The list is always longer than you expect. When you’re ready to go further, the OpenShell documentation and the OpenShell repository are the places to start.