From the Red Hat edition of October 29, 2026
We audited OpenShell's source. The design holds and the defaults do not.
AI Gen Apps (independent engineering review) · Agent runtime security: independent source-code review · Global (software review)
- Publisher
- AI Gen Apps
- Original publication
- AI Gen Apps engineering paper, Oct. 23, 2026
- Source retrieved
- 2026-10-30
- Event date
- 2026-10-23
What happened
A source-code review of NVIDIA OpenShell, the agent sandbox Red Hat says it is integrating into Red Hat AI, was read at commit bc4c8f0 on Oct. 23, 2026. It finds that enforcement outside the agent process is real and fails closed at startup. Several defaults are permissive: L7 request rules default to audit (log and forward) unless enforcement is set; endpoints without a protocol field get no method or path rules; the user filesystem policy defaults to best effort; binary allow rules also authorize descendant processes; credentials are substituted outbound but responses are not scrubbed. On Kubernetes, egress isolation depends on the cluster network plugin enforcing NetworkPolicy. The review also cites an NVIDIA bulletin of Aug. 25 listing six OpenShell vulnerabilities, two rated 9.9, fixed in 0.0.34.
Why it matters
Directly relevant to any state, local or university team evaluating Red Hat AI agent hosting on OpenShift. The controls Red Hat markets for agent safety only work as advertised when configured explicitly. The audit's checklist (enforce mode, hard filesystem requirement, manual approval, NetworkPolicy-enforcing CNI) can become procurement and acceptance requirements.
Evidence and measured results
Read the full audit page. The method is code and documentation reading at a fixed commit; the authors state they did not build or run OpenShell. Findings are labeled as either read in code paths or stated in project documentation. No exploit testing or benchmark was performed. The vulnerability list is reported from NVIDIA's bulletin as summarized by the authors; the bulletin itself was not opened for this edition.
Limitations and uncertainty
Code reading only, no runtime testing. Snapshot of a fast-moving project. Published by a company that sells AI products and services. Reviews NVIDIA's upstream code, not a Red Hat-packaged build.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-30; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Security leaders need assurance that agent sandboxes actually block unauthorized actions before approving agent pilots.
- Stakeholders
- CISO / security architecture
- Platform engineering
- Internal audit
- Agency AI governance board
- Discovery questions
- Who will own and review agent sandbox policies?
- Does your Kubernetes network plugin enforce NetworkPolicy today?
- What evidence does your security review need before an agent gets credentials?
- Value hypothesis
- A documented hardening baseline and validation tests can shorten security review for agent pilots compared with reviewing each agent from scratch.
- Potential engagement
- Agent sandbox hardening assessment and validation test suite for one pilot environment.
- Unsupported claims
- That OpenShell defaults are secure out of the box
- That sandboxing prevents all data exfiltration
- That findings apply unchanged to future Red Hat-packaged releases
Pre-sales engineering
Role takeaway
- Fit
- Applies wherever OpenShell is used or planned as the agent runtime on OpenShift or Podman.
- Architecture and integration
- Sandbox policy files under version control, containment checker in CI, NetworkPolicy-enforcing CNI, and tenant authorization in a gateway above the sandbox.
- Prerequisites
- OpenShell 0.0.34 or later (0.1 series current per the audit)
- CNI with NetworkPolicy enforcement
- Policy repository and CI pipeline
- Constraints
- Findings are a code-reading snapshot
- Kubernetes user namespaces off by default
- No response scrubbing of credentials
- Security
- Set enforce mode, hard filesystem requirement and manual approval. Prefer exact hosts and specific tool binaries. Treat every allowed endpoint as an exfiltration path.
- Proof of value
- Attempt a write against a read-only rule and confirm it is blocked, not just logged
- Confirm sandbox pods cannot bypass policy on the customer's CNI
- Confirm an approved API echoing a header does not expose a real credential in the test scenario
Delivery
Role takeaway
- Work
- Write and maintain hardened sandbox policies, CI containment checks and negative acceptance tests for agent environments.
- Dependencies
- Upstream OpenShell release cadence
- Red Hat packaging timeline
- Security team test approval
- Ownership
- Platform engineering owns policies; the CISO office approves changes.
- Skills and adoption
- Policy-as-code and Kubernetes network-policy training for platform staff.
- Governance checkpoints
- Policy review before each agent onboarding
- Re-review after each OpenShell version change
- Monthly review of audit-mode logs
- Acceptance criteria
- Proposed: zero endpoints left in audit mode at go-live
- Proposed: containment check passes in CI for every policy change
- Proposed: all negative egress tests blocked
- Risks
- Silent audit-mode policies
- Policy drift as the project changes quickly
- Over-reliance on the sandbox in place of authorization
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
On OpenShift, agent sandbox isolation depends on the cluster's network plugin enforcing NetworkPolicy and on user namespaces, which the audit says are off by default. Architects should treat the sandbox as one layer beneath tenant authorization and audit, not as the authorization layer.
Governance
Who approves, reviews and stays accountable for outcomes?
Policy changes should be reviewed manually; the audit warns that operators can switch approval to automatic, and that the formal prover is not what gates approvals. It recommends running the containment checker against a written boundary policy in CI.
Security and privacy
What data, permissions and controls need testing?
Exfiltration paths remain through any allowed endpoint, and real credentials can reach the agent if an approved API reflects them in responses. Request bodies are not inspected by default.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Secure configuration requires policy-as-code expertise that many SLED IT teams lack, which argues for templates and training.
Procurement
What should contracts, pricing and exit terms secure?
Solicitations for agent platforms can require documented enforce-mode defaults, CNI NetworkPolicy validation and minimum patched versions rather than accepting 'sandboxed' as a checkbox.
Operating model
Which teams own the service once it runs?
The project moves fast (the audit cites roughly eight commits a day), so findings can date within weeks. Platform owners need a recurring review cadence.
Publication history
- 2026-10-29Red Hat · Issue 018 resources
Stable resource ID: aigenapps-openshell-source-audit-defaults-20261023