Strategic PartnersIssue 018 records
Red Hat
First red-hat edition. Red Hat's AI story this month centers on agent safety and sovereign, self-hosted AI, while the independent evidence centers on the operating work those claims require. Red Hat and NVIDIA announced the OpenShell agent-sandbox reference architecture, and an independent source audit found the design sound but the defaults permissive. A Critical OpenShift AI 3.5.2 errata and an upstream vLLM code-execution advisory show the patching load of self-hosted AI. A preprint found unguided AI-generated Ansible consistently insecure. On the deployment side, UNC's on-premises health assistant and a German classified AI cloud remain pre-production, and New England's research cloud paused its OpenShift AI services during a platform rebuild.
- Evidence records
- 8
- Cross-source patterns
- 3
- Evidence classes
- 4 vendor claim2 independent research1 academic research1 public-sector association guidance
- Outcomes
- 5 cautionary3 emerging
- Source freshness
- 4 new this fortnight3 recent1 undated
- Research completed
- 2026-10-30
Choose a role to see its takeaway beside every record in the ledger.
Patterns across the evidence
Synthesis · Lighthouse Advisory interpretation
Agent safety is being sold as a platform layer, but its defaults need hardening
Red Hat and NVIDIA position OpenShell sandboxing and a governed model gateway as the way to make agents safe on Red Hat AI. An independent source audit finds the enforcement design sound but key defaults permissive: audit-mode request rules, best-effort filesystem policy and no response scrubbing. In addition, the integration itself is still in progress.
Operating questionBefore hosting agents on Red Hat AI, who will own sandbox policy, enforce non-default settings, and prove egress and credential controls with negative tests?
Supporting evidenceRed Hat (with NVIDIA)AI Gen Apps (independent engineering review)
Self-managed Red Hat AI makes patching and upstream tracking a customer duty
A Critical OpenShift AI 3.5.2 errata spanning gateway, RAG, evaluation and pipeline images, and an upstream vLLM code-execution advisory tied to non-default configuration, show that self-hosted AI platforms carry a recurring vulnerability-management load across vendor and upstream channels.
Operating questionDoes the agency have a patch SLA, an inventory of inference endpoints and an owner who maps upstream advisories to deployed Red Hat builds?
Supporting evidenceRed Hat Product SecurityvLLM project (open-source upstream of Red Hat AI Inference Server)
Institution-controlled AI depends on approvals, staffing and continuity, not just the platform
A German sovereign AI cloud still awaits validation and approval, a UNC assistant runs on premises but remains pre-production with a planned non-profit handoff, and a regional research cloud paused its OpenShift AI services because it could not run old and new platforms at once.
Operating questionWho will fund, staff, accredit and sustain the self-hosted AI service after the pilot, and how will users move if the platform changes?
Supporting evidencesecunet Security Networks AG (with Red Hat, deepset, NVIDIA)University of North Carolina at Chapel Hill (School of Nursing, Computer Science, RENCI)New England Research Cloud (NERC) / Mass Open Cloud
Evidence ledger
Full record · every source keeps its link and limitations
Red Hat AI Factory with NVIDIA accelerates agentic AI security capabilities across the open hybrid cloud
Vendor claim: Red Hat says it is working with NVIDIA on the OpenShell Reference Architecture, an open-source agent sandbox runtime, and is actively collaborating to integrate it into Red Hat AI and Red Hat AI Factory with NVIDIA as a native platform capability. The release also describes a joint inference reference design with Model-as-a-Service access control, an AI gateway, vLLM and llm-d, plus self-service model discovery, rate limiting and entitlement tracking. The integration is described as in progress. The release gives no general-availability date, customer deployments or performance measurements.
Why it matters, evidence and limitations
- Why it matters
- Relevant to state CIO offices, university research IT and large county IT shops that are being asked to host AI agents on-premises or in a sovereign hybrid cloud. Per-tenant model access control, rate limiting and showback match how shared-service IT organizations charge back agencies or departments. No SLED customer is named, so applicability is inferred.
- Evidence and measured results
- Read the full press release on redhat.com. It is a forward-looking vendor announcement with a forward-looking-statements disclaimer. No benchmark, test method, sample or customer outcome is reported. The NVIDIA hardware claim that Vera CPUs deliver 2X faster agentic CPU performance comes from NVIDIA and gives no baseline.
- Limitations and uncertainty
- Vendor announcement only. The OpenShell integration is not yet a shipping native capability, no SLED deployment is cited, and performance claims have no independent validation.
We audited OpenShell's source. The design holds and the defaults do not.
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, evidence and limitations
- 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.
RHSA-2026:86891: Critical security advisory with updated images for Red Hat OpenShift AI 3.5.2
Red Hat issued RHSA-2026:86891 on Oct. 21, 2026, rated Critical, providing updated container images for Red Hat OpenShift AI 3.5.2. The advisory lists many CVEs (including CVE-2024-14029 and numerous 2026 CVEs) and updated images for components including the AI gateway, AutoRAG, AutoML, EvalHub, dashboard, data science pipelines and Feast operators. Customers are directed to the OpenShift AI upgrade documentation to fully apply the errata.
Why it matters, evidence and limitations
- Why it matters
- State, local and university teams running self-managed OpenShift AI own patching. A Critical rating on the current 3.5.x line, spanning the components marketed for governed RAG and agents, means AI platform operations must follow the same vulnerability-management SLAs as other critical infrastructure.
- Evidence and measured results
- Opened the errata page and read the summary, severity, issued and updated dates (both 2026-10-21), the affected-product description, the CVE list and the image list. Individual CVE details were not opened, so which CVEs drive the Critical rating, and whether they are exploitable in typical configurations, is not established here.
- Limitations and uncertainty
- A vendor advisory states severity and fixed images but not exploitability in specific deployments. CVE-level details were not reviewed for this edition.
vLLM advisory GHSA-h3rc-6mm3-gc2m: request-controlled code_revision allows remote code execution
The vLLM project published a High (8.1) advisory on Oct. 6, 2026 affecting vllm >=0.7.3 and <0.31.0, patched in 0.31.0, with no CVE assigned. An untrusted multimodal request can set mm_processor_kwargs.code_revision and make vLLM import processor Python code from another revision of the served model repository. This is arbitrary code execution in the API/renderer process. It applies only when the operator has enabled trust_remote_code, the model processor uses dynamic auto_map code, and an attacker can control a revision in that repository. The default trust_remote_code=False is not affected. The advisory also notes that /tokenize is not covered by vLLM's API-key middleware unless an external proxy protects it.
Why it matters, evidence and limitations
- Why it matters
- VLLM is the inference engine inside Red Hat AI Inference Server and OpenShift AI model serving. State, local and university teams that serve community multimodal models with trust_remote_code enabled, or expose vLLM endpoints directly to campus or agency networks, carry this class of risk. Whether a given Red Hat build is affected depends on its bundled vLLM version, which this edition did not verify.
- Evidence and measured results
- Read the full GitHub advisory: affected and patched versions, preconditions, request path analysis, the reporter-suggested CVSS 9.8 versus the published 8.1 score with high attack complexity, and remediation guidance. The advisory includes an offline proof of concept. It was not reproduced. No Red Hat errata mapping to this advisory was opened.
- Limitations and uncertainty
- Red Hat engineers are major contributors to vLLM, so this upstream source is not fully independent of the vendor. The CVSS 8.1 rating assumes a specific non-default configuration. Mapping to Red Hat product versions was not verified.
secunet, Red Hat and deepset present AI offering for classified information based on NVIDIA technologies
Vendor claim: a consortium of secunet, Red Hat and deepset, using NVIDIA technology, confirmed at NVIDIA GTC Berlin (Oct. 20 to 22, 2026) that it is developing a classified-information-compliant AI Runtime as a Service for German authorities. secunet cloud would run it in its own German data centers. It builds on the SINA Cloud architecture on NVIDIA BlueField-3 DPUs, Red Hat AI Factory with NVIDIA for containerized AI operations, Haystack for agent orchestration and Nemotron open models. secunet says the SINA Cloud security components are BSI-authorized for classified information. The new offering itself still needs integration, validation, approval and release before secunet will provide it.
Why it matters, evidence and limitations
- Why it matters
- International comparator for US state and local agencies with criminal justice, tax, health or other restricted data that want AI under government-controlled, in-country or in-state operation. It shows Red Hat AI positioned as the platform layer inside a regulated sovereign service, with accreditation inherited from an existing authorized cloud. US equivalents would map to CJIS, IRS 1075 or StateRAMP rather than German VS rules.
- Evidence and measured results
- Read the full secunet release (dated 10/26/2026). It is a forward-looking consortium announcement: no customers, pricing, availability date or performance data. Approval for the new offering is pending, so the BSI authorization claim covers existing SINA Cloud components, not this service.
- Limitations and uncertainty
- Vendor consortium announcement; not yet available; non-US regulatory context; no outcomes or customers reported.
University of North Carolina builds human-centered AI assistant (SARHAchat) on Red Hat OpenShift AI
Vendor claim: UNC's School of Nursing, Computer Science department and RENCI moved SARHAchat, a sexual and reproductive health assistant for 18 to 25-year-olds, from a general-purpose LLM prototype built over 2 years to Red Hat OpenShift AI. Working with Red Hat pre-sales, the team built a prototype in 2 weeks. It reports smooth switching between informational and consultative modes, safety checks for basic health screening, and a move from a model of more than 500 billion parameters to a 20-billion-parameter model, which the team says gives faster responses on less infrastructure. The system and data are hosted on premises on NVIDIA hardware. Public testing and interviews are still under way, and the long-term aim is handoff to non-profit organizations.
Why it matters, evidence and limitations
- Why it matters
- A public university case of on-premises generative AI for sensitive health information. It is relevant to university research IT, academic medical centers and state public-health agencies weighing self-hosted, smaller models for sensitive-topic assistants. The planned handoff to non-profits highlights sustainability and maintainability questions that SLED programs face after grant-funded pilots.
- Evidence and measured results
- Read the web case study (datePublished 2026-09-16) and the linked PDF. All metrics come from vendor marketing with customer quotes: a prototype in 2 weeks and a 500B-to-20B model reduction. No user outcomes, accuracy, safety evaluation results, cost figures or usage numbers are reported. The assistant is still being tested with members of the public, so this is a pre-production result.
- Limitations and uncertainty
- Vendor-published case study, pre-production, with no independent evaluation or quantitative outcomes beyond model size and prototype speed. No event date is given for the migration.
Evaluating and Preventing Security Smells in AI-Generated Ansible Code (Preprint, not peer reviewed)
Preprint, not peer reviewed. The authors evaluated 16 AI models generating Ansible roles for Apache Tomcat 10 and MongoDB 7 and analyzed 278 roles (including human-written roles from Ansible Galaxy) against CIS Level 1 benchmarks, using deployment testing with CIS-CAT Pro. Without security guidance, all 16 models produced code with security smells, such as hardcoded credentials, and underperformed human roles. With structured prompts embedding Ansible best practices and CIS controls (an extended CO-STAR framework), 4 of 16 models produced compliant code. The best reached 95 to 100% CIS compliance against 23 to 43% for human-written roles. The other 12 failed to follow multi-constraint instructions.
Why it matters, evidence and limitations
- Why it matters
- State and local IT teams and university system administrators are adopting AI assistants for Ansible automation, including Red Hat Ansible Lightspeed. The study suggests unguided AI-generated playbooks are likely to miss CIS hardening controls that many state security standards reference. Prompt-embedded standards and post-deployment compliance scans should be required, whichever assistant is used.
- Evidence and measured results
- Read the arXiv abstract page and the PDF. Two applications only (Tomcat, MongoDB), CIS Level 1 controls, zero-shot baseline prompts, deployment validation with CIS-CAT Pro. Red Hat Ansible Lightspeed and IBM Granite code models were not among the models tested, so results do not directly measure Red Hat's product.
- Limitations and uncertainty
- Preprint, not peer reviewed. Limited to two applications and CIS Level 1. Red Hat's assistant was not tested. Model versions will age quickly.
NERC service suspension and data preservation FAQ: regional research cloud with OpenShift AI paused while MOC 2.0 is built
The New England Research Cloud said its current services, including OpenStack, OpenShift and OpenShift AI (RHOAI) workbenches and model serving, would be suspended on July 31, 2026, because it lacks resources to maintain them while building a new platform under the MOC name. That platform is intended to support NIST 800-171 and HIPAA workloads. NERC said it would not migrate projects. Users had to export and verify data, notebooks, models and configurations themselves. The suspension was expected to last several months. MOC 2.0 timelines, quotas, GPUs, onboarding and approvals are not yet set, and endpoints, quotas and GPUs are not guaranteed to return.
Why it matters, evidence and limitations
- Why it matters
- A rare public account of a shared academic OpenShift AI platform pausing service. It is directly relevant to universities and state research consortia that host shared AI platforms for faculty and courses. It shows that platform continuity, export responsibility and regulated-data readiness are operating-model risks separate from the technology itself.
- Evidence and measured results
- Read the full FAQ page. The page is undated; the July 31, 2026 suspension date is stated in the text. It is an operator notice to users, not an evaluation. It gives no figures on affected users, projects or costs, and does not explain the funding or staffing situation beyond lacking resources to run both platforms.
- Limitations and uncertainty
- The page is undated, so the publication date is unknown. It is an operator FAQ with no quantitative impact data. The Red Hat product role is inferred from listed services (OpenShift, RHOAI).
How to read this edition
Source findings, measured results and limitations come from the cited publications. Patterns, operating questions, role takeaways and implementation considerations are Lighthouse Advisory interpretation, stated as questions to validate locally rather than guaranteed outcomes. Vendor and operator claims are labeled as claims. Full research method.
- Vendor claim
- A supplier-provided assertion that has not been upgraded to independent evidence.
- Independent research
- Research conducted outside the implementing organization.
- Academic research
- Research produced through an academic institution or peer-reviewed venue.
- Public-sector association guidance
- Practitioner guidance or an association-supplied case; not independent outcome evidence.