SpaceX and Nvidia say they are adapting the Vera Rubin NVL72 rack-scale AI platform for orbital use, with SpaceX targeting a first launch in the fourth quarter of 2027. 

The dream of an AI data center in space lives on in SpaceX and Nvidia’s August 24 announcements that the platform for Low Earth Orbit (LEO) Starmind AI satellites will be based on the Vera Rubin NVL72 chip family and architecture.

This proposed system would form the computing core of SpaceXAI’s first-generation Starmind AI satellite and extend Nvidia’s architecture from terrestrial AI data centers into space. 

SpaceX CEO Elon Musk posted on X the same day, “SpaceX, in partnership with Nvidia, has designed a space-optimized Vera Rubin NVL72 system for launch to orbit in Q4 next year, with significant scale in 2028.”

SpaceX, in partnership with Nvidia, has designed a space-optimized Vera Rubin NVL72 system for launch to orbit in Q4 next year, with significant scale in 2028 https://t.co/qdDq8YBkzl

— Elon Musk (@elonmusk) August 24, 2026

Musk’s post came after he said during SpaceX’s Q2 earnings call, “Going forward, we’ve decided to build exclusively on Nvidia because we think the Vera Rubin architecture is the best architecture.” Musk continued, “This is not some sort of far-future, distant thing; we expect to start launching these next year. We think the design of the NVL72 VR computer is a much better design than, say, having a standard rack -style design. So we expect to deploy this on the ground as well as in orbit, because we think it’s going to be a radical simplification of the standard NVL72 rack. It will cost less. It will be more effective. If we’re going to put it in space, why not want to put it on the ground? I think that’s going to be pretty cool.”

On Earth, the Vera Rubin NVL72 is Nvidia’s rack-scale AI design that combines 72 Rubin GPUs and 36 Vera CPUs, alongside high-speed networking components such as ConnectX-9 SuperNICs. Nvidia says SpaceXAI’s planned Starmind satellite will be based on an optimized version of that system.

A conventional NVL72 rack assumes gravity, technicians, stable grid power, a building-scale liquid loop and frequent replacement of failed parts. Orbit removes each of these assumptions.

The idea is more ambitious than putting a conventional edge-AI accelerator aboard a spacecraft. Nvidia and SpaceXAI are proposing to bring a modified architecture used in AI data centers into orbit, while altering it for orbital operational requirements.

Getting that working in orbit, though, is easier said than done. 

As Curtis Pyke, founder of Kingy AI, writes, “A conventional NVL72 rack assumes gravity, technicians, stable grid power, a building-scale liquid loop and frequent replacement of failed parts. Orbit removes each of these assumptions.“

“Cooling is unforgiving. Space is cold, but vacuum does not carry heat away through convection.”

In particular, Pyke continues, “Cooling is unforgiving. Space is cold, but vacuum does not carry heat away through convection. Heat must travel from the chips to the radiator surfaces and then leave as infrared radiation. SpaceX says AI1 can avoid chillers, cooling towers and fans and reduce cooling overhead by an order of magnitude.”

SpaceX explains that AI1 would instead use closed-loop liquid cooling inside the spacecraft and large deployable radiators to send heat directly to space as infrared radiation. While the claimed reduction is physically plausible in principle, there’s no proof yet that these AI satellites’ cooling systems can deliver. 

Another major problem that remains unaddressed is how to make the orbital rack radiation-tolerant. Making Vera Rubin NVL72 radiation-tolerant means far more than putting an ordinary NVL72 rack in a shielded satellite enclosure. It would require a system-level redesign of its GPUs, CPUs, memory, networking, power, cooling, firmware, and operations around a specified orbit and mission life.

LEO orbit is not benign. NASA cites typical trapped-particle dose rates of 100 to 1,000 rad(Si) per year for low-inclination LEO spacecraft below 500 km. That level of radiation is not an immediate death sentence for electronics, but over a multiyear mission it will cause cumulative degradation. Radiation-qualified space hardware can deal with that. Commercial Off-The-Shelf (COTS) electronics are another matter. A true radiation-hardened Rubin GPU would also require design changes at the transistor and circuit levels. 

Even were Nvidia to make such a chip, for a high-density AI system such as the SpaceX design, the concern isn’t simply whether one processor survives a 5- or 10-year dose. The satellite contains numerous radiation-sensitive elements, such as GPU logic, SRAM caches, register files, system memory, and memory controllers. With thousands of cores and billions of memory storage cells, the aggregate fault rate — not the behavior of an individual component — drives the design.

The most realistic near-term answer would be a radiation-tolerant, fault-managed Rubin-derived orbital system, not a fully radiation-hardened NVL72 in the traditional military-space sense. It could use selected commercial Nvidia parts, substantial shielding, ECC and data integrity mechanisms, redundant controllers and power paths, aggressive fault detection, software recovery, and reduced-performance operating modes.

The post SpaceX designed an orbital Vera Rubin. Radiation comes next. appeared first on The New Stack.

AI data centers in space sound great, but practically speaking, they may be next to impossible.

For tech bros, it sounds great. Two of the buzziest tech giants, SpaceX and NVIDIA, are partnering together to bring AI data centers into space using the just-announced Starmind AI1 satellite. 

These 30-meter-tall satellites with a 75-meter solar-array wingspan will contain the latest NVIDIA Vera CPUs and Rubin GPUs. These will live in a Low Earth Orbit (LEO) of about 600 kilometers. For networking, it will use Starlink’s laser links. SpaceX says the first AI1 spacecraft will perform localized AI computing in orbit and relay results to Earth via Starlink. 

According to SpaceX, AI1 is designed around a compute payload drawing up to 250 kW at peak and 175 kW on average. It will be solar-powered, unlike its Earth-bound competitors, which frequently require the construction of new power plants.  

Starmind is not simply a conventional NVIDIA AI cluster launched into orbit. The effort hinges on integrating high-density accelerator hardware with a spacecraft platform capable of generating power, rejecting waste heat, surviving radiation, maintaining laser communications, and being produced in large quantities. None of that is easy. 

Once in orbit, which will require SpaceX’s still-not-ready-for-prime-time Starship rockets to launch the estimated 2.3-metric-ton satellites, the satellites will work together. 

Eventually, to reach SpaceX’s goal of a million (that’s not a typo, that’s a million) Starmind satellites, the two companies will need to design a standard model spacecraft. These will be built in SpaceX’s 11-million-square-foot manufacturing campus, Gigasat Factory, which is still under construction in Bastrop County, Texas.

This AI-in-space proposal is the most ambitious yet of SpaceX CEO Elon Musk’s dream of placing energy-intensive AI infrastructure in orbit. There, these satellites won’t need to compete for land, electrical-grid capacity, or water with increasingly contentious terrestrial data center buildouts. 

However, SpaceX glosses over the technical issues of turning this vision into reality.

Cooling space data centers

Let’s start with the biggest headache: Cooling.

Contrary to what you may think from bad science-fiction movies, the vacuum of space is not cold per se. Whether the surface of an object is hot or cold depends entirely on whether it’s facing the sun. Those on the sun side will heat up, while those away from the sun will eventually cool down toward the 3 Kelvin background of deep space.

The keyword is “eventually.” You can’t simply use convection, cooling towers, or evaporative cooling to carry away heat. The heat must radiate away as infrared radiation, and that’s a very slow process. 

The physics creates a direct trade-off between computing power, radiator area, spacecraft mass, and operating temperature. A system running hundreds of kilowatts of AI hardware must reject nearly all of that power as waste heat. Liquid cooling can carry heat away from chips, but it does not eliminate the requirement for extensive radiator surfaces.

As NASA has found, “satellites experience harsh environments in orbit,” ranging from about 393 Kelvin in full sun (248 degrees Fahrenheit) all the way down to ~3 Kelvin (-454 degrees Fahrenheit).  

To cool down the Starmind satellites, each will have a deployable liquid radiator system measuring 160 square meters. What liquid? We don’t know yet. Hugh Lewis, a professor of astronautics at the University of Birmingham, expects it to use ammonia, which is already used on the International Space Station (ISS). Whether this will reliably scale to data-center-class AI deployments with their enormous heat remains to be seen. 

Networking limits in orbit

Another issue is its networking. The architecture depends heavily on Starlink’s optical inter-satellite links. SpaceX says AI1 satellites will use high-speed laser links to communicate with other spacecraft and send AI results to Earth via the Starlink network. 

Starlink’s published technology specifications describe mini laser terminals operating at up to 25 Gbps across distances as long as 4,000 kilometers, while SpaceX cites roughly 25-millisecond latency for its customer service. 

Those figures suggest a potentially useful network for distributing inference results, transmitting model updates, connecting orbital sensors to compute nodes, and avoiding some reliance on ground-station passes. But they do not establish that a satellite constellation can function like the tightly coupled networking fabric of a terrestrial AI supercomputer.

We won’t be seeing large-scale machine learning and training in space. This requires huge, predictable bandwidth and very low latency for GPU-to-GPU communications. An orbital network would also face physical propagation delays, laser-link acquisition and handoffs, routing across a moving constellation, and limits on available capacity per spacecraft. 

Debris, war and solar storms

Another issue, according to Doug Mohney, a long-time space influencer, is debris. “One bad day, a piece of random junk hits one satellite, which fragments into multiple pieces of shrapnel, which hits another satellite and so on and so on until you get a Kessler event that turns the selective orbit into a roaming cloud of debris.”

A Kessler event is when one satellite breaks up, and its fragments hit another, and so on until an area of LEO is filled with wreckage rather than viable satellites. 

Adding insult to injury, a Kessler event may not happen by accident. Mohney also observes that space warfare is a real threat: “A bad actor such as  Russia, China, Iran, or North Korea could use kinetic (unrandom junk!) means to target one or more satellites, resulting in space debris.” Or, “One good nuclear weapon uses an electromagnetic pulse to get rid of all of them at once. Both Russia and China (and the US) already have anti-satellite weapons (ASAT) programs. North Korea could have ASAT, but a nuke would ensure mass destruction of orbital capability.” 

If that sounds crazy, keep in mind that Starlink satellites are already being used by Ukraine, and Russia has been trying to block their transmissions. There have also been credible reports of Russia developing ASAT weapons specifically designed to knock Starlink satellites out of the sky. Larger and more fragile Starmind satellites would be far more vulnerable.

Mohney also worries about the “known unknown” of space weather.

“A Solar flare that hit the Earth along the lines of the 1859 Carrington Event, the largest recorded solar storm, would take out orbital electronics of all satellites.” This, in turn, as uncontrolled satellites drift from their orbit, might cause a Kessler event.  Lesser events have already pushed LEO satellites out of space. For example, a February 2022 geomagnetic storm forced thirty-eight newly launched Starlink satellites out of orbit. 

The $170 billion question

There are also business concerns. For all the obstacles that new and expanded ground-based AI data centers face, the energy analytics firm Wood Mackenzie believes “A hypothetical 1 GW orbital data center would cost an estimated $170 billion, more than three times the equivalent terrestrial facility, with launch and satellite costs accounting for approximately 60% of that total. To bring orbital costs to parity with terrestrial alternatives would require a 70% reduction.” 

The company thinks that might be possible, but Robert Liew, Wood Mackenzie Research Director, observes, “That gap does not close without sustained and dramatic progress on launch costs. We forecast US$ 9 trillion of terrestrial data center investment between now and 2040. That is where capital goes first. Orbital data centers are a serious long-term proposition, but right now they remain a bet on the cost curve.”

For now, SpaceX has offered a broad technical vision and a hardware partnership with NVIDIA, but few of the operational metrics that would establish commercial viability. The real test will be whether SpaceX Starship becomes a practical launch vehicle and can overcome its cooling and safety issues. Then, the AI1 must also show enough usable compute per kilogram, kilowatt, square meter of radiator, and dollar of launch cost to outperform or complement ground-based AI infrastructure. I don’t see this happening anytime soon. 

The post Why space is actually a terrible place to cool a data center appeared first on The New Stack.

According to OpenAI, the Hugging Face security breach was an “unprecedented cyber incident, involving state-of-the-art cyber capabilities.” Critics may disagree.

Back in 2018, for example, academics predicted that new attacks might “arise that would be impractical for humans alone to develop or which exploit the vulnerabilities of AI systems themselves.”  Well, here we are.

What escaped the sandbox

So, what really happened? OpenAI reports an autonomous security-evaluation run of GPT‑5.6 Sol and a pre-release model broke out of a sandbox, reached the internet, and then targeted Hugging Face to try to solve the ExploitGym benchmark.

By OpenAI’s account, “an internal evaluation which prompts models to pursue advanced exploitation using complex attack paths … [with] maximal cyber capabilities by running this evaluation without production classifiers used to prevent models from pursuing high-risk cyber activity.” 

OpenAI continues, “Our benchmarks run in a highly isolated environment, with network access constrained to the ability to install packages through an internally hosted third-party software that acts as a proxy and cache for package registries.”

“All evidence suggests that the models were hyperfocused on finding a solution for ExploitGym, going to extreme lengths to achieve a rather narrow testing goal.”

The AI models, however, cracked their sandbox. Once out, they “identified and chained vulnerabilities across OpenAI’s research environment and Hugging Face’s production infrastructure to obtain test solutions directly from Hugging Face’s production database. All evidence suggests that the models were hyperfocused on finding a solution for ExploitGym, going to extreme lengths to achieve a rather narrow testing goal.”

AI expert Ken Huang describes the process in a blog post: “The model spent enormous inference budget probing the sandbox, then found a zero-day in the third-party software OpenAI used as a package-registry proxy and cache.

“It used that bug to gain unrestricted internet access. It then reasoned that Hugging Face probably hosted the ExploitGym datasets, chained stolen credentials with several more vulnerabilities into a remote code execution path, and pulled the benchmark answers straight out of Hugging Face’s production database.”

Why intent no longer matters

This was not, as John W. Larson, president and chief AI officer of the AI security company Babel Street, tells The New Stack, a “Terminator” moment. OpenAI models and agents “[were not] acting out of malice or trying to attack Hugging Face. It encountered obstacles, developed an unexpected strategy, bypassed safeguards, and pursued its assigned goal in a way its creators never anticipated. The incident demonstrates that harmful cyber incidents no longer require malicious intent: Only highly capable autonomous AI optimizing for an objective.

Harmful cyber incidents no longer require malicious intent: Only highly capable autonomous AI optimizing for an objective.

That’s the first issue we must be aware of. Software attacks no longer require a hacker. All it needs is an LLM freed of guardrails with a mission to accomplish, and it will take whatever steps are needed to reach its goal. 

In addition, Adam Boynton, senior enterprise security manager of EMEIA at the Apple Identity and Access Management company Jamf, tells The New Stack, “This happened inside a frontier lab deliberately stress-testing its most capable models, in conditions no enterprise would ever run.”

Boynton also notes that this episode confirmed that “AI tools are no longer just applications people open. They act on the user’s behalf, with the user’s access. So every organization needs a clear view of which AI tools its people are running, and how those tools are configured and used.”

An agent given too much power is far more capable than a user armed with a superuser password of causing havoc both to your systems and to ones far outside your control. 

Where container isolation failed

As for the attack itself, Edera CMO Kaylin Trychon writes in a blog post, “This incident deserves more attention than ‘an AI did the hacking now.’ The interesting part isn’t who was driving, or even that it was a model instead of a person. It’s where the walls gave way, twice, in two different companies’ infrastructure — and that part is entirely familiar to anyone who’s spent time securing container infrastructure.” 

Exactly so. Trychon continues, “Strip away the framing and this is a story about two escalation chains, back to back.” The first consisted of “The model found and exploited a zero-day in that proxy, then used privilege escalation and lateral movement inside OpenAI’s own ‘highly isolated’ testing environment until it reached a node with open internet access.”

Next, OpenAI’s models inferred, correctly,  that “Hugging Face likely hosted the datasets, models, and reference solutions for the benchmark it was trying to solve. It chained stolen credentials with a remote-code-execution path into Hugging Face’s servers, harvested more credentials, and moved laterally into several internal clusters over a weekend, all in pursuit of one narrow goal: Finding the answer key.”

“The failure that actually matters is what a single code-execution event is allowed to become — and notably, that failure happened the same way twice, at two different companies, in the same incident.”

The serious issue, from Trychon’s perspective, is that “both companies’ blast radius was a cluster instead of a container.”

That’s because “the failure that actually matters is what a single code-execution event is allowed to become – and notably, that failure happened the same way twice, at two different companies, in the same incident. In a typical container fleet, workloads share a kernel.

“A process that gets popped, or a model that gets a shell, is one syscall boundary away from the node it’s running on, and the node is one set of mounted credentials away from the rest of the cluster. Namespaces and cgroups are process-isolation primitives, not security boundaries — they were never designed to hold against an attacker (human or model) that already has code execution and time.”

People might not have been able to do this easily. But as Bloomberg succinctly put it, “OpenAI Models Spent Hours on Hack That Usually Takes Weeks.” Exactly so. We can expect to see more such successful attacks. 

Beyond the sandbox paradigm

Edera’s CTO and co-founder Alex Zenla tells The New Stack, “The sandbox escape here isn’t really the surprising part of this attack. An entire market of AI sandboxing tools has exploded over the past couple of months, and this is the reality they’re all built on top of: containers, VMs via namespaces — whatever the branding — most of them still share a kernel with the host or with each other.

“That’s a boundary enforced in software, and software boundaries are exactly the kind of thing an agent that can try ten thousand escape paths over a weekend is going to find a way through. We shouldn’t be shocked that this happened; we should be shocked at how many teams are still betting their infrastructure on technology that was never designed to withstand such a persistent adversary. The fix isn’t a better sandbox; it’s getting out of the sandbox paradigm entirely.”

Zenla continues, “Teams should adopt secure execution environments that are hardware-enforced and eliminate the shared kernel flaw. This technology exists today and would have made this specific escalation chain structurally impossible, not just harder. Teams running agents with real permissions and real access need to stop treating this as a someday problem, because the next version of this week is already being tested somewhere right now.”

That underlines the most important issue of all. Thanks to AI, security attackers are coming harder and faster than ever. Security can no longer be an afterthought.

As Jim Zemlin, the Linux Foundation CEO, said at the 2026 Open Source Summit North America, “the exploit time for a zero-day vulnerability being exploited has shrunk from 63 days to -7 days.”

You literally no longer have time to wait for security fixes. You must bake in as much security as you can as fast as you can, or your systems will be broken into. It’s as simple as that. 

The post What really happened in the Hugging Face breach appeared first on The New Stack.