Beyond container boundaries: Kernel-level agent security in Red Hat OpenShift AI 3.5

77% of organizations now have AI agents running in production.¹ The adoption curve is steep. The governance curve is not. Agents operate over-permissioned and often without full security sign-off. Many are operating in what IDC calls a "governance grey zone." Shadow AI incidents cost, on average, $670,000 more than standard security incidents.

The problem is architectural, not attitudinal. Teams want governance, but they lack the tools. AI agents that browse the web, execute code, query databases, and call APIs represent a fundamentally different security challenge from traditional workloads. A traditional service account has a defined permission set; an agent has a conversational interface that can convince itself (or be convinced) to take actions its operators never anticipated. 

Container boundaries alone are not enough when an agent has filesystem, network, and shell access, highlighted by one of the more recent, high-profile agent escapes. Guardrails built at the model layer can be reasoned around by the same model they're protecting against.

Enterprises need something the large language model (LLM) cannot negotiate with: kernel-enforced boundaries that the operating system (OS) itself provides.

Today, Red Hat OpenShift AI 3.5 ships OpenShell agent sandboxing as a Developer Preview, the 1st step toward making that enforcement a standard feature of the Red Hat AI platform.

Red Hat's defense-in-depth story for AI agents

Agent security is not a single control. It is a stack of independent layers, each covering a different attack surface. Here is how OpenShell fits within the broader Red Hat AI security posture:

Layer 0 — Kernel isolation: OpenShell sandboxing. Three independent enforcement layers—Landlock LSM, seccomp filters, and network namespace isolation—are each backed by the Linux kernel. The OS enforces boundaries, not the agent's own code. A prompt injection that tells an agent to exfiltrate credentials or read /etc/passwd hits a kernel-level wall before any application logic runs.

Layer 1 — Policy enforcement: OPA at L4 and L7. OpenShell's Open Policy Agent engine controls what agents can reach at both the TCP connection level (L4) and the HTTP request level (L7, by URL path, method, and headers). Policies are declarative, hot-reloadable, and version-controlled. This approach provides deterministic policy enforcement that blocks regardless of what the model decides to do.

Layer 2 — Semantic guardrails: NeMo Guardrails. Runtime content policy runs at 5 pipeline stages: Input, retrieval, dialog, execution, and output, with execution rails that wrap every tool call with pre- and post-invocation validation. This is where prompt injection propagation into tool actions is caught. Configured in YAML and Colang, it exposes an OpenAI-compatible endpoint so it slots into existing agent stacks without code changes.

Layer 3 — Adversarial testing: Red teaming with Garak. An open source red teaming framework systematically probes agent behavior against known attack patterns: Jailbreaks, prompt injections, tool misuse, goal hijacking. It runs offline against agent configurations and in continuous integration as regression tests. It finds the gaps that sandboxing and guardrails need to close.

Layer 4 — Supply chain: Signed base images and agentic harnesses. We build OpenShell container images through Konflux, producing FIPS-compliant UBI9 images with RPM lock files, SBOM artifacts, and check-payload validation. Beyond the runtime, we ship pre-built, signed harness images for popular AI coding agents like Codex, Goose, OpenClaw, OpenCode, and Pi, available at quay.io/aipcc/base-images/agentic/. Teams run these inside an OpenShell sandbox without building and vetting their own containers. Supply chain security starts before the agent runs.

No single control is sufficient. The platform makes them compose.

What customers are asking for

The demand pattern we're seeing across financial services, telecommunications, and enterprise platform teams converges on 4 requirements that no existing platform addresses together.

Deterministic policy enforcement: Machine learning-based guardrails are valuable, but they cannot provide the binary guarantee that regulated industries need. Financial services firms and telecommunications operators moving agents into production systems need to prove to auditors that an agent could not have accessed a specific resource, not just that it probably didn't. That requires kernel-level enforcement, not probabilistic content filters.

Regulatory traceability: The EU AI Act's Article 14 requires full human oversight and traceability for high-risk AI systems. U.S. financial services regulators are pushing similar requirements. Security teams need structured audit trails–what happened, when, and why it was allowed or denied, in a format that existing SIEM investments can ingest. Not operational metrics—security telemetry.

Credential protection at the platform layer: Agents frequently need access to credentials, model API keys, and downstream service tokens. But the agent's runtime context is also the place most vulnerable to prompt injection. Injecting credentials into the sandbox environment without exposing them to the agent's execution context is a hard requirement for any production deployment.

A governance floor that central IT sets and teams cannot weaken: As IDC found, over 40% of organizations have accepted that agent development platforms will proliferate and are standardizing on orchestration and governance as the unifying layer. The platforms that win will be the ones where teams can build freely within a governance baseline they didn't have to build themselves.

OpenShell, as a Developer Preview in Red Hat OpenShift AI 3.5, is the beginning of that answer on Red Hat's AI platform.

What Is OpenShell? 

OpenShell is an open source agent runtime built around a simple premise: Agents should have exactly the access they need, no more, and every action should be observable and attributable. It combines sandbox controls and declarative YAML policy into a single runtime that deploys on existing infrastructure.

Three governance primitives define the programming model:

• Policy as Code (PaC): Network, filesystem, and process policies are declarative YAML checked into version control. Central IT sets a floor, teams extend within it. There is no ambient trust, no implicit access.
• Structured security events: Every network connection, file access, syscall, and HTTP request emits a structured event in OCSF v1.7 format, the same format that Splunk, QRadar, and Azure Sentinel understand natively. Security teams get the audit trail regulators ask for without building custom log parsers.
• Live observability: The openshell termTUI shows OCSF events as they arrive, with ALLOWED/DENIED verdicts and the binary that triggered each event. Watch an agent's behavior in real time or pipe events to a SIEM for post-hoc analysis.

OpenShell is an open source industry collaboration backed by NVIDIA, Red Hat, Docker, GitHub, SAP, Google, and Dell. It’s vendor-neutral at the sandbox layer by design.

OpenShell — The technical approach

The core insight is that application-layer controls are in the wrong place. An agent's execution context—the Python interpreter, the shell, the network stack—is precisely what a sophisticated prompt injection aims to compromise. Controls at that layer can be bypassed if the agent is manipulated. Controls at the kernel layer cannot.

Landlock LSM enforces filesystem access at the kernel level. The sandbox specification defines allowed read/write paths at creation time - /usr, /lib, /etcread-only; /sandbox and /tmp read-write. A prompt injection telling the agent to exfiltrate credentials or write outside its working directory hits a kernel-level wall before any Python runs.

Seccomp filters the system call surface. Privilege escalation paths and dangerous syscalls are blocked in the kernel before they can execute. The agent cannot exec unexpected binaries or change its own resource limits.

Network namespace isolation controls what the agent can reach at the IP layer. Combined with the OPA policy engine, this creates two independent enforcement points:

• L4 (TCP): Block by destination IP and port. The connection never leaves the node that the namespaced pod runs on.
• L7 (HTTP): Inspect by URL path, method, and headers. Allow GET /api/v1/public but block DELETE on the same host.

Policies are hot-reloadable, update them without restarting the sandbox or interrupting the agent.

The OCSF v1.7 event stream is what makes this auditable. Four event categories, including network activity, HTTP activity, process activity, filesystem activity, flow as structured security telemetry. This is intentionally distinct from operational observability (OTel traces, Prometheus metrics): It is what a security operations center reads, not what a platform engineer monitors.

The policy advisor: Agents that propose their own permissions

The most novel element of OpenShell's design is how it handles the tension between a default-deny posture and the reality that agents operate in environments where the full egress requirements are not known upfront.

Every sandbox starts with no outbound access. When an agent attempts a connection that policy denies, OpenShell returns a structured 403 body - not a generic error, but a response that tells the agent exactly what rule is missing and what a valid proposal looks like:

{
  "layer": "opa",
  "host": "api.github.com",
  "port": 443,
  "binary": "/usr/bin/gh",
  "rule_missing": true,
  "next_steps": "Submit an addRule proposal to http://policy.local/v1/proposals"
}

The agent reads its policy advisor skill, inspects the current policy via GET /v1/policy/current, and submits a narrowly scoped addRule proposal. A developer reviews and approves or rejects from outside the sandbox. A rejection reason is returned to the agent so it can draft a narrower request.

For low-risk expansions, auto-approval mode runs a formal prover before any hot-reload:

• link_local_reach - dDes the rule reach link-local or cloud metadata addresses?
• l7_bypass_credentialed - Does an uninspectable protocol gain reach to a credentialed host?
• credential_reach_expansion - Does a binary gain credentialed reach to a previously unreachable destination?
• capability_expansion - Does a new HTTP method appear on an already-credentialed (binary, host, port)?

If all 4 pass and no security notes are generated, the policy hot-reloads automatically. Every auto-approval emits a CONFIG:APPROVED OCSF event with auto=true and prover_delta=empty - the governance trail is maintained even when no human reviewed it.

The structured rule is the approval contract. The agent's reasoning is context. The governance machinery doesn't trust the model's judgment about whether its own access expansion is safe.

Getting started

Prerequisites: Red Hat OpenShift 4.21+, the openshell CLI (v0.0.85), and LLM provider credentials. The full guide in the agent-ops repository covers everything end-to-end in about 15 minutes.

# 1. Install OpenShell via Helm
ROUTE_HOST="openshell.$(oc get ingresses.config.openshift.io cluster \
  -o jsonpath='{.spec.domain}')"
helm install openshell oci://ghcr.io/nvidia/openshell/helm-chart \
  --version 0.0.85 --namespace openshell \
  --set "pkiInitJob.serverDnsNames[0]=${ROUTE_HOST}"
# Expose the gateway
oc create route passthrough openshell \
  --service=openshell --port=8080 --hostname="${ROUTE_HOST}" -n openshell
# 2. Create a sandbox
openshell sandbox create --name my-sandbox
# 3. Run a coding agent inside it
ANTHROPIC_BASE_URL="https://inference.local" \
ANTHROPIC_API_KEY=unused \
CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 \
claude --bare

Open openshell term in a second terminal to watch OCSF security events arrive in real time:

NET:OPEN [MED] DENIED  /usr/local/bin/claude(43) -> github.com:443 [policy:- engine:opa]
                       [reason: endpoint github.com:443 is not allowed by any policy]
NET:OPEN [INFO] ALLOWED /usr/bin/curl(118) -> github.com:443 [policy:my-sandbox engine:opa]

Egress is deny-by-default. Add access when you need it - the policy advisor handles the negotiation:

openshell policy update my-sandbox \undefined  --add-endpoint github.com:443:read-only:rest:enforce \undefined  --binary /usr/bin/curl --wait

What comes next

This Developer Preview is the foundation. The platform will mature to include an operator for lifecycle management, SPIFFE-based agent identity, declarative deployment, and deeper observability integration, making governed agent execution progressively easier to adopt and harder to misconfigure. If you hit something missing or broken, open an issue. That feedback directly shapes what comes next in the OpenShift AI 3.6 Tech Preview.

Try it

The getting started guide, inference routing walkthrough, and MLflow tracing demo are all in the agent-ops repository.

The guides cover Helm installation, mTLS setup, provider registration, sandbox creation, egress policy management, and routing inference traffic through an OpenShift AI-served model without exposing credentials to the sandbox.

The agents your teams are deploying right now deserve a runtime the OS guarantees, not just guardrails that the model can reason around.

¹ IDC White Paper, sponsored by Red Hat. “AgentOps: Operationalizing Agentic AI for Safety at Scale.” Document #US54644926, July 2026