On October 21, 2026, SUSE became a launch partner for NVIDIA’s OpenShell Reference Architecture, six months after it first put the OpenShell agent sandbox into SUSE AI Factory with NVIDIA. With SUSE, Red Hat, and Canonical all offering the same runtime, buyers will choose based on what each platform can demonstrate that an agent has done.
What is Covered in this Article
- What SUSE announced at NVIDIA GTC Berlin on October 21, 2026, and what it says is available.
- How OpenShell keeps an agent’s limits outside the agent’s control.
- Where Red Hat and Canonical stand with the same runtime and NVIDIA’s DPUs.
- What OpenShell records about agent activity by default, and what SUSE says about its own audit telemetry.
- What platform teams, the Linux vendors, and NVIDIA should do before agent controls count as audit evidence.
The News: On October 21, 2026, at NVIDIA GTC Berlin, SUSE said it is integrating the NVIDIA OpenShell Reference Architecture into SUSE AI Factory with NVIDIA as a launch partner. The architecture pairs NVIDIA Vera Rubin for inference, Vera CPUs running OpenShell for agent execution, and BlueField-4 data processing units (DPUs) running NVIDIA Sentry “for host-independent monitoring and in-silicon policy enforcement.” NVIDIA says its Open Agent Safety Platform, launched September 28, 2026, “consists of” the Apache 2.0 OpenShell runtime and the Sentry reference design.
SUSE lists three outcomes: supervisor proxies that inspect agent traffic and “block unauthorized network requests,” agent code that runs “within the corporate perimeter,” and a private model serving on NVIDIA NIM that “eliminates third-party per-token public API fees.” SUSE also introduced SUSE Linux Enterprise Server (SLES) for NVIDIA, built on SLES 16 for day-zero support of new NVIDIA hardware and scheduled for general availability in November 2026.
SUSE first included the OpenShell runtime when it announced SUSE AI Factory with NVIDIA at SUSECON on April 21, 2026, as a preview “expected to be available later this year.” The October release gives no availability date for the OpenShell integration, and an October 8 SUSE blog says other NVIDIA platform components are “planned for future” releases. Mexico’s Guanajuato Secretariat of Finance is testing SUSE AI Factory with NVIDIA in a proof-of-concept. Details are in SUSE’s October 21 announcement.
SUSE OpenShell Agent Security: Enforcement Is Table Stakes, Proof Is Not
Analyst Take: SUSE now offers NVIDIA‘s OpenShell sandbox for its customers’ agents, as do Red Hat and Canonical. Once all three offer the same runtime, OpenShell agent security is no longer a reason to choose one over the others. The reason becomes proof of what an agent did.
SUSE’s own reason for the move is sovereignty. It calls itself “the leading sovereign open infrastructure company” and made the announcement at GTC Berlin. Proof starts with the platform team.
Red Hat, Canonical, and SUSE Now Offer the Same Agent Sandbox
Red Hat said in March 2026, the same month Futurum wrote that OpenShell should become the agentic AI foundation layer, that OpenShell “can be deployed on Red Hat AI.” SUSE announced SUSE AI Factory with NVIDIA with the OpenShell runtime at SUSECON on April 21, and on May 20, Red Hat’s engineers described an OpenShift driver that “runs each agent as a Kubernetes pod with full policy enforcement.” Canonical previewed an OpenShell snap for Ubuntu on June 1 and released a Charmed OpenShell alpha on September 28.
Red Hat already supports NVIDIA’s DPUs. In October, it described agent monitoring from NVIDIA’s DOCA Argus running on BlueField DPUs, outside the host, “anchored by the generally available support for NVIDIA BlueField-3 DPUs in Red Hat OpenShift 4.22.” SUSE’s blog lists the rest of NVIDIA’s platform as planned.
What SUSE adds this month is the launch-partner role for NVIDIA’s reference architecture, “Kubernetes sandboxing and API gateways alongside OpenShell,” as well as telemetry through SUSE Observability.
OpenShell Agent Security Enforces the Limit but Doesn’t Yet Guarantee the Record
In OpenShell agent security today, enforcement is on by default, and a complete, exportable record is not. NVIDIA’s March 23 blog promises “a full audit trail of every allow and deny decision,” and its own documentation for the current release, v0.1.5, describes something narrower.
SUSE’s blog states the enforcement principle OpenShell is built on: “The harness guides what an agent tries; the infrastructure has final authority over what it can do.” The harness is the software that runs the agent’s loop and calls its tools, and because OpenShell’s controls run outside the agent’s process, a prompt injection or a compromised dependency can’t disable them.
Final authority over an action is not proof of it. In September, Fernando Montenegro, Brendan Burke, and Mitch wrote that the telemetry gap was still open, because NVIDIA described “a tamper-proof record of agent activity but not where it goes.” NVIDIA’s OpenShell documentation now shows what that gap looks like in software.
OpenShell records security events, such as policy decisions, network connections, and process starts, in the Open Cybersecurity Schema Framework (OCSF), a common format that security tools read. A shorthand version still appears in OpenShell’s console logs without extra setup. Sending the full events to an OpenTelemetry collector, the documentation says, “is off by default, even when trace export is on.”
NVIDIA’s page on OCSF JSON output adds: “Collection is best-effort, not a guarantee of complete audit history.” Nothing in the OpenShell observability documentation describes signed event records, and the “attested telemetry” NVIDIA describes comes from Sentry, which runs on BlueField-4 DPUs.
Enterprises need that record. They have already watched agents step out of bounds. In The Futurum Group’s 2H 2026 Software Lifecycle Engineering Global Enterprise Decision Maker Survey (n=839, fielded June 2026), 75% of organizations had a production incident in the previous 12 months in which AI was a contributing factor, and 36% of those said AI agents had executed unintended or out-of-scope actions.
When asked which controls they have in place for agents in their software development environment, only 45% of organizations named audit logging of agent actions. A sandbox can stop the next out-of-scope action. For the other 55%, it leaves a usable record only if someone turns export on.
SUSE Calls Its Agent Telemetry Immutable but Hasn’t Shown How
SUSE’s own blueprint requires a human decision before a sandbox starts and before code merges. In the SecOps agent workflow SUSE described on October 8, research agents have no write access, and action agents run inside OpenShell sandboxes.
Most organizations haven’t drawn that line yet. In the same survey, only 32% have human approval gates for irreversible agent actions. SUSE sends the traces to SUSE Observability and says, “Immutable OTLP telemetry generates audit trajectories and scan diffs.” SUSE chose that word, so that is the bar the claim has to clear.
Neither SUSE’s blog nor its release says what makes the records immutable, whether they include OpenShell’s OCSF security events or only traces, or whether the guarantee holds without NVIDIA DPUs.
The workflow is also SUSE’s own, not a customer’s, and the release doesn’t say whether Guanajuato’s proof of concept uses OpenShell. Sovereignty, SUSE’s headline, raises the same question of proof. Keeping a model within the company’s environment does not prevent an agent from sending data through an approved tool or external service. Buyers need to trace the path from the agent to the model, repository, and operational systems, including who can change permissions.
Platform Teams Should Demand the Sandbox and Test the Record
- Platform engineering teams: start with a narrow remediation pilot, turn on OCSF export to the security information and event management (SIEM) system you already run, and measure accepted fixes, engineer review time, blocked prohibited actions, and the completeness of the audit record. The platform team owns the setting; the security team owns the review.
- SUSE, Red Hat, and Canonical: say whether your builds of OpenShell agent security send OCSF security events to your observability stack by default, and whether the audit record can be shown unaltered without NVIDIA DPUs.
- NVIDIA: enable OCSF export by default before OpenShell reaches 1.0, and document how a software-only deployment can prove its records are complete.
CIOs – Make the Audit Record a Condition of Purchase
The platform team owns the “solves the problem” decision. The audit exposure does not stop there. When a regulator, an auditor, or the board asks what an agent did within a production system, the question lands on the CIO’s and CISO’s desks, and they can answer only with the records that actually exist. That is the buyer’s proof gap, and it determines who has to care about the decision before anything reaches production.
Sovereignty has been SUSE’s headline since 2025. For the regulated and sovereign buyers, it gates the purchase. A buyer can confirm where the model runs at signing. But what agents reach on the way there and what agents do with approved tools are what need the exportable record. A sovereignty claim without it checks the checkbox in the RFP and leaves the accountability question for the auditors and incident review teams.
The economics claim deserves this same scrutiny. Eliminating third-party per-token API fees removes a variable cost line item and replaces it with the fixed cost of serving and operating models on NVIDIA infrastructure, plus the people to run it. At an enterprise scale, that can be the right decision. It is a total-cost decision. The per-token price sheet is what the vendor shows. The infrastructure, DPU, and operations actuals are what the CFO questions when price sheets don’t match production realities.
None of this is specific to one vendor. Make the exportable, tamper-evident audit record an acceptance condition so governance is proven at procurement. Buyers who treat the record as a feature flag to turn on later take on governance and audit debt that won’t surface until the first incident review.
What to Watch
- Whether SUSE’s KubeCon North America announcements in November 2026 give an availability date for OpenShell in SUSE AI Factory with NVIDIA, and whether Sentry joins it.
- Whether NVIDIA turns on OCSF event export by default in an OpenShell release before 1.0.
- Whether SUSE, Red Hat, or Canonical publishes a tamper-evident agent audit record that works without NVIDIA DPUs.
- Whether a regulated customer, Guanajuato, or another, passes the test Futurum set in March by moving an OpenShell-governed agent into production and publishing what its auditors accept.
See the complete announcement from SUSE at NVIDIA GTC Berlin on the SUSE website.
Declaration of generative AI and AI-assisted technologies in the writing process: This content has been generated with the support of artificial intelligence technologies. Due to the fast pace of content creation and the continuous evolution of data and information, The Futurum Group and its analysts strive to ensure the accuracy and factual integrity of the information presented. However, the opinions and interpretations expressed in this content reflect those of the individual author/analyst. The Futurum Group makes no guarantees regarding the completeness, accuracy, or reliability of any information contained herein. Readers are encouraged to verify facts independently and consult relevant sources for further clarification.
Disclosure: Futurum is a research and advisory firm that engages or has engaged in research, analysis, and advisory services with many technology companies, including those mentioned in this article. The author does not hold any equity positions with any company mentioned in this article.
Analysis and opinions expressed herein are specific to the analyst individually and data and other information that might have been provided for validation, not those of Futurum as a whole.
Read the full Futurum Group Disclosure.
Other Insights from Futurum:
NVIDIA Simulates Fault-Tolerant Quantum at 104 Qubits
Intel D-Series GPUs Make HBM Optional for Agentic Inference
Qodo v3.1: Governing AI Code Review Before Noise Kills Adoption
Author Information
Vikram Rathnam is Research Director, Software Lifecycle Engineering at The Futurum Group. His research examines how software is built, tested, secured, and operated as AI agents move from assisting developers to doing the work. His coverage includes observability, platform engineering, and the control planes that govern agents. Before joining Futurum, he spent 24 years on the vendor side: ten in engineering at Silicon Labs and fourteen in product and partner strategy, with roles at Cisco, Secureworks, Dell, and CMIT Solutions. Across those roles, he managed B2B cybersecurity, IoT, and AI products, with partner and channel ecosystems as the common thread. At CMIT Solutions, he led product strategy across a franchise network of 180 locations. He reads a vendor’s roadmap as someone who has had to ship one and take it to market.
Mitch Ashley is VP and Practice Lead for the CIO & Technology Buyers and Software Lifecycle Engineering practices at The Futurum Group. A multi-time CIO and CTO with 30+ years leading technical organizations, Mitch built and operated production systems spanning cybersecurity for the U.S. Department of Defense, PKI services for the broadband and 5G industries, SaaS platforms, large-scale telecom and banking systems, and a national broadband network. His work with AI began early, developing expert systems that diagnosed and repaired complex mainframe environments. That operator foundation grounds his analysis in operational consequence, covering the technology buyer's world of software engineering, cybersecurity, DevOps, cloud, and AI.
