Five OpenShift agent harnesses expose the gap between sandboxed and production-ready

A Red Hat AI Services field repository packages five OpenShift demonstrations around NVIDIA OpenShell, coding agents and sandbox policy. Read together, the demos are less a claim that agents are “safe” than a map of how much capability each harness still needs.

The collection targets OpenShift 4.19 or later and requires cluster-admin access for setup. It presents opinionated companion configurations, not supported product documentation or a production certification.

Four controls, three very different permission sets

Every sandbox combines four layers described by the guide: outbound network default-deny through an HTTP CONNECT proxy, network rules bound to named executables, Landlock filesystem restrictions, and an unprivileged sandbox process under OpenShift Security Context Constraints.

Those controls are common; the policy tier changes the practical blast radius.

• Strict allows the inference endpoint and no general external egress. It is the baseline used by the basic OpenShell demo and one side of the Escape the Shell challenge.
• Standard adds package registries, read-only GitHub access and optional MLflow tracing. OpenCode with Keycloak and the Hermes agent use this tier.
• Permissive grants GitHub write access plus direct Anthropic, OpenAI and Google Vertex endpoints for trusted coding agents. The Claude Code demo uses it.

Binary binding sharpens those network rules. A host can be reachable for python3 or node while remaining blocked for another executable. Filesystem policy separately declares read-only and read-write paths, and the agent runs without root privileges.

What the five demos actually prove

The basic demo proves that a sandbox can start with narrow egress and test network, filesystem and process restrictions. The OpenCode path adds Keycloak OIDC, inference through LiteLLM and MLflow integration. Claude Code demonstrates the opposite end of the permissions spectrum: an agent that can write to GitHub and call external model APIs, but only through an explicit host-and-binary allowlist.

Escape the Shell is the most useful review aid because it switches between policies and tests the boundaries directly. The Hermes example shows that an autonomous agent can fit the middle tier rather than automatically receiving the broadest policy.

The collection therefore does not offer five equivalent security postures. It offers five workloads with different dependencies, identities and consequences.

The production-readiness boundary

Several lines remain outside the sandbox policy itself.

First, Keycloak authentication appears in the OpenCode path; it is not evidence that every demo has per-user identity or authorization. Second, MLflow tracing is optional and does not by itself establish audit completeness. Third, the permissive Claude policy explicitly allows GitHub writes and direct AI APIs. A compromised or misdirected agent would still be able to act within those approved destinations.

The guide also configures Landlock compatibility as best_effort. Teams should verify the effective kernel enforcement on their worker nodes rather than treating the YAML declaration as proof. Network policy can be hot-reloaded, while filesystem and process policy are fixed when the sandbox is created.

For production evaluation, start with strict, add endpoints and binaries only from observed workload requirements, separate read from write credentials, and test denied operations in CI. Identity, secret delivery, audit retention, resource quotas, image provenance and human approval for consequential writes still need platform controls around the harness.

The repository’s strongest contribution is making permission expansion reviewable. “Sandboxed” is a runtime property; production readiness is the narrower question of whether every remaining capability is necessary, attributable and recoverable.