OpenShell puts agent policy below the model—and credentials outside the workload
Red Hat’s implementation notes show how process identity, network controls and human-approved policy changes fit into an agent sandbox.
Red Hat has supplied the implementation detail behind its OpenShell work with NVIDIA: the proposed control point sits below the model, identifies the process making a request and keeps credentials outside the agent workload. That makes the new engineering post less a launch reprise than a concrete security architecture for teams putting autonomous agents on real infrastructure.
What the control layer does
According to Red Hat, OpenShell gives each agent, session or both a separate execution environment. Its enforcement layers include Landlock, seccomp, user and network namespaces, and Layer 7 inspection. A policy engine mediates filesystem, process and network access, while a gateway checks actions before they reach the host.
The notable detail is that network policy is process-aware. OpenShell identifies the binary initiating an outbound connection and verifies its SHA-256 hash before evaluating the rule. A team can therefore allow the approved agent runtime to reach an endpoint without granting every process in the sandbox the same path.
Red Hat also says credentials remain outside the workload and are injected at the network boundary. A compromised agent would not hold the secret itself. Denied connections are emitted as structured Open Cybersecurity Schema Framework events, giving security teams an observable failure rather than a silent one.
Who keeps authority
OpenShell’s design does not ask the model to police itself. Prompt guardrails can still help, but infrastructure policy remains effective when the model is persuaded to behave badly. When an agent encounters a blocked action, it can propose a policy change; a person retains approval authority.
That division matters for platform teams choosing between agent frameworks. Red Hat says it validated the enforcement model across three sandboxing patterns: enclosing the whole agent, isolating its execution environment, or isolating only generated code. The tests covered different frameworks on both Podman and Red Hat OpenShift.
What teams can try now
The first reference architecture is NVIDIA’s Secure Agent Workspace design. Red Hat describes a dedicated workspace virtual machine for each user, OpenShell at the execution boundary, enterprise single sign-on, GitOps-managed policy and no shared agent process space. The company says the pattern is available for validation and feedback while its integration of OpenShell into Red Hat AI continues.
For practitioners, the immediate task is inventory rather than installation: identify which credentials, databases and internal services current agents can reach. That map determines where process-specific egress policy and boundary-injected credentials would reduce risk. The open question is productization—Red Hat calls native Red Hat AI integration active work, not a generally available capability in this post.
sources
- Why Red Hat is building secure agent onboardingwww.redhat.com
comments · 0