Strategic PartnersIssue 074 records
Red Hat
A controls-and-runtime day for Red Hat AI. vLLM's Nov. 4 day-0 support for Moonshot Kimi K3.1 Pro brings measured sparse-attention and AgentX lab gains across NVIDIA, AMD, TPU and Zhenwu—while its quick start enables --trust-remote-code. Red Hat's CVE-2026-114053 record, still listing residual Affected fast-channel, RHEL AI and OpenShift AI packages after the Nov. 3 Inference fixes, states remote code stays disabled by default on Red Hat AI. Separately, IBM Cloud documented Virtual Private Endpoints for Red Hat AI Inference (Nov. 2), and IT Brief's Nov. 5 coverage framed Red Hat–NVIDIA AI Factory around OpenShell agent sandboxes, governed vLLM/llm-d inference and Vera Rubin day-zero plans. No new U.S. SLED deployment evaluation surfaced.
- Evidence records
- 4
- Cross-source patterns
- 2
- Evidence classes
- 2 vendor claim1 independent research1 independent reporting
- Outcomes
- 3 emerging1 cautionary
- Source freshness
- 3 new this fortnight1 recent
- Research completed
- 2026-11-06
Choose a role to see its takeaway beside every record in the ledger.
Patterns across the evidence
Synthesis · Lighthouse Advisory interpretation
Day-0 model quick starts collide with Red Hat's trust_remote_code default-deny
The Nov. 4 vLLM Kimi K3.1 Pro day-0 guide documents --trust-remote-code, while Red Hat's CVE-2026-114053 statement says Red Hat AI keeps remote code disabled by default and still lists residual Affected packages after the Nov. 3 Inference fixes. SLED operators need a controlled exception path, not copy-paste upstream flags.
Operating questionBefore any day-0 multimodal model lands on Red Hat AI Inference or OpenShift AI, is trust_remote_code explicitly denied in production ServingRuntimes and covered by a written exception process?
Supporting evidencevLLM Project / InferactRed Hat Product Security
Put agent and inference controls outside the model path
Independent Nov. 5 coverage stresses OpenShell controls enforced outside the agent and governed vLLM/llm-d inference, while the Nov. 2 IBM Cloud note shows private-network endpoint separation for Red Hat AI Inference. Together they point to control planes (sandbox, gateway, private path) rather than prompt-only guardrails.
Operating questionFor each agentic or managed-inference pilot, which controls sit outside the model—sandbox, gateway entitlements and private networking—and who operates them?
Supporting evidenceIT Brief UK (TechDay)IBM Cloud (community blog by Luca Ioffredo)
Evidence ledger
Full record · every source keeps its link and limitations
vLLM ships day-0 support for Moonshot Kimi K3.1 Pro across NVIDIA, AMD, TPU and Zhenwu, with measured AgentX and sparse-attention gains
On Nov. 4, 2026 the vLLM project published day-0 serving support for Moonshot AI's Kimi K3.1 Pro, a 2.8T-parameter (104B active) multimodal MoE with 1M-token context and Sparse Attention (DSA) on all 24 full-attention layers. Support spans NVIDIA GPUs, AMD GPUs, Google TPUs and Alibaba T-Head Zhenwu PPUs. The post reports measured gains including up to 1.69× faster TTFT versus head-sharded prefill at 340K tokens on 8× GB300, decode 1.2–1.6× faster on a fused DSA path, and SemiAnalysis AgentX peaks of 375.9 tok/s per user (GB300) and 815.6 tok/s per user (Rubin). Quick-start commands enable --trust-remote-code and tool/reasoning parsers. Zero-mismatch RL (bit-identical log-probs with Megatron) is claimed for day-0. Figures are vendor/project lab measurements, not SLED field results.
Why it matters, evidence and limitations
- Why it matters
- Red Hat AI Inference and OpenShift AI model-serving stacks are built on vLLM, so day-0 multi-accelerator support for a large open-weight multimodal model expands what research universities, state AI hubs and local-government platform teams can trial on hybrid Red Hat platforms—without a Red Hat-specific SLED deployment being documented here. The documented --trust-remote-code quick start is operationally material for public buyers (see companion CVE-2026-114053).
- Evidence and measured results
- Project blog dated November 4, 2026; TL;DR and architecture sections describe DSA indexer, packed KV cache, DCP, fused decode and AgentX numbers; NVIDIA/AMD quick-start blocks include --trust-remote-code. No independent third-party replication or public-sector case study is included.
- Limitations and uncertainty
- Benchmarks are project/lab results on GB300/Rubin and AMD configurations; transferability to typical state/university GPU fleets is unproven. Moonshot/Kimi provenance and export-control review is out of scope of this post. Not a Red Hat product advisory.
Red Hat CVE-2026-114053: Important vLLM multimodal RCE when trust_remote_code is on; AI Inference 3.5.3 fixes some images while 'fast', RHEL AI and several OpenShift AI packages stay Affected
Why now: after the Nov. 3 Red Hat AI Inference 3.5.3 wave already covered in the Nov. 4 edition, this CVE record remains the operator-facing statement of exploit conditions and residual Affected packages. CVE-2026-114053 (Important) describes unauthenticated RCE via attacker-controlled multimodal processor code_revision when trust_remote_code is enabled (vLLM 0.7.3 before 0.31.0). Red Hat rates it Important, not Critical, because exploitation needs non-default settings; the statement says Red Hat AI deployments disable remote code execution by default. Affected releases list Nov. 3 fixes under RHSA-2026:94702/94709/94717/94721/94738 for several rhaii/vllm-* images, while package_state still marks numerous rhaii-fast/* images, multiple RHEL AI 3 bootc images, and several OpenShift AI odh-vllm/kserve/llm-d packages Affected.
Why it matters, evidence and limitations
- Why it matters
- State, local and education operators running OpenShift AI, RHEL AI or Red Hat AI Inference must treat trust_remote_code enablement—including flags copied from day-0 model blogs—as a privileged change, and must track which image streams remain Affected after the Nov. 3 advisories. Federal KEV-style urgency does not automatically apply, but public-sector IR playbooks still need a clear default-deny posture for dynamic processor loading.
- Evidence and measured results
- Red Hat Security Data JSON and portal page for CVE-2026-114053: threat_severity Important; statement on default-disabled remote code; details on /tokenize multimodal code_revision path; affected_release entries dated 2026-11-03; package_state rows showing Affected for fast-channel and several RHOAI/RHEL AI packages. This is vendor security status, not an independent exploit write-up.
- Limitations and uncertainty
- CVE public date is Oct. 21; included now because residual Affected state and the default-deny statement are newly actionable beside Nov. 4–5 day-0 model guidance. No evidence of in-the-wild exploitation against SLED tenants is provided.
IBM Cloud adds Virtual Private Endpoint access for Red Hat AI Inference, keeping the same API over a private network path
An IBM Cloud community post dated Nov. 2, 2026 states that Red Hat AI Inference on IBM Cloud now supports Virtual Private Endpoint (VPE) access. Applications can send inference requests over the IBM Cloud private network via a dedicated private API hostname while keeping the same project ID, authentication (IBM Cloud IAM), API operations and payloads—only the endpoint hostname changes. The author positions VPE as complementary to existing authz for RAG, internal assistants and agents that send enterprise context to inference. No throughput, latency or SLED case metrics are provided.
Why it matters, evidence and limitations
- Why it matters
- State agencies, public universities and health systems that already run workloads on IBM Cloud and consume Red Hat AI Inference can reduce public-internet exposure for prompts and retrieved documents by switching hostname configuration. This is a networking control for a Red Hat AI product, not a watsonx feature story; applicability is limited to IBM Cloud tenants and is not a general on-prem OpenShift AI pattern.
- Evidence and measured results
- IBM Community blog with article:published_time 2026-11-02T10:02:12.177Z; descriptive how-to and rationale; no independent verification, no packet-capture proof and no customer deployment named.
- Limitations and uncertainty
- Vendor/partner blog, not a Red Hat advisory. Limited to IBM Cloud VPE. No measured security or performance outcome. Broader IBM watsonx platforms are out of scope except as adjacent hosting context.
Independent IT Brief coverage: Red Hat and NVIDIA expand AI Factory around OpenShell agent controls, governed vLLM/llm-d inference and Vera Rubin day-zero enablement
IT Brief UK published Nov. 5, 2026 coverage of an expanded Red Hat–NVIDIA AI Factory collaboration. The article highlights OpenShell as an open-source agent sandbox with controls enforced outside the agent; a governed inference reference design combining Model-as-a-Service access control, an AI Gateway, vLLM and llm-d with NVIDIA Dynamo/NIM; support statements for NVIDIA Nemotron 3.5 Super VL via vLLM and LLM compressor demos (FP8, DSpark); and day-zero enablement plans for NVIDIA Vera Rubin infrastructure plus RHEL support for NVIDIA Vera CPUs. Quotes from Red Hat's Joe Fernandes and NVIDIA emphasize externalized policy enforcement. No SLED deployment results or independent benchmarks are presented.
Why it matters, evidence and limitations
- Why it matters
- SLED buyers evaluating agentic automation on Red Hat AI should treat this as signal that Red Hat is productizing external agent sandboxes and MaaS governance with NVIDIA—relevant to state AI factories, university research platforms and local-government automation programs—while recognizing it is announcement-level coverage without measured public-sector outcomes. Transferability caveat: hardware (Vera Rubin) availability timelines for government purchasers are not established here.
- Evidence and measured results
- IT Brief news article with datePublished 2026-11-05T21:30:00+13:00; paraphrases vendor claims and quotes executives; does not inspect code, configs or customer sites. Related OpenShell/AI Factory themes were discussed in earlier October material; this piece adds Vera Rubin/Vera CPU and Nemotron 3.5 Super VL framing in a Nov. 5 independent outlet.
- Limitations and uncertainty
- Trade press summary of vendor messaging. No independent evaluation. Partner-channel availability claims are unverified. Not evidence of a U.S. SLED deployment.
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.
- Independent reporting
- Independent reporting with attributable sources but without a formal evaluation design.