Red Hat AI 3.5 Brings OpenShell into OpenShift to Constrain Agent Side Effects with Kernel-Level Policies

In [AI 3.5](https://www.redhat.com/en/blog/red-hat-ai-35-scaling-and-governing-ai-agents-production), Red Hat brings the NVIDIA-led OpenShell agent sandbox to OpenShift AI, where it is currently available as a Developer Preview. The point is not to add another layer of prompt filtering, but to let the operating system and external policy engines decide which side effects an agent may cause: the Landlock LSM restricts file paths, seccomp filters dangerous system calls, and a dedicated network namespace isolates connections. OPA can enforce L4/L7 egress policies based on destination, port, executable, HTTP method, path, and headers.

The [OpenShell architecture](https://github.com/NVIDIA/OpenShell/blob/main/architecture/sandbox.md) divides a workload into a privileged supervisor and an unprivileged agent child. The former establishes isolation, proxies network traffic, and injects configuration, while the latter clears its capability bounding set before startup. If privileges cannot be removed correctly, workload creation or the opening of an SSH shell should fail. Credentials are not exposed directly to the agent, either: the environment contains only opaque placeholder tokens, which the egress proxy replaces with real credentials only when a request satisfies both the network policy and its host, port, and path bindings.

Red Hat also combines this execution boundary with NeMo Guardrails, Garak red-team testing, and supply-chain controls. NeMo Guardrails can inspect content during the input, retrieval, dialogue, tool-execution, and output stages. Agent images are built through Konflux and include UBI9, an RPM lock file, an SBOM, and signature verification. The platform also provides prebuilt agent harnesses for Codex, Goose, OpenClaw, OpenCode, and others, reducing inconsistencies that arise when teams assemble base images themselves.

However, “kernel enforcement” should not be equated with complete isolation. [NVIDIA’s policy documentation](https://docs.nvidia.com/openshell/reference/policy-schema) shows that Landlock defaults to `best_effort`: if the kernel ABI is unsupported or policies cannot be applied to all paths, the system may issue a warning and continue running. Deployments that require guaranteed fail-closed behavior must switch to `hard_requirement`. OpenShell itself is also still labeled alpha, while its Kubernetes and multi-tenant paths continue to evolve. Teams preparing to evaluate it should verify node kernel versions, policy failure behavior, encrypted-traffic inspection, GPU device exposure, audit-log completeness, and CRD and policy compatibility during upgrades.