How Do NeoCloud Providers Protect AI Training Data Moving Between Remote GPU Data Centers?

NeoCloud providers including CoreWeave, Lambda, and Nebius build GPU capacity where land is available, but this also makes these GPU farms far from the networks that use them. Model weights, training corpora, and checkpoints cross the WAN links between those sites. Standard security practice is for this data to traverse as encrypted traffic, however they remain physically recordable.Β
β
RAND's 2024 report on securing AI identifies 38 distinct attack vectors against model weights and the data behind them. A remote site extends the opportunity in which a fiber junction box or an exposed cable run can be reached and exploited before it can be detected. Carmel, our photonic layer security platform, alters the optical signal to protect the data inside it, so a tap anywhere along long expanses of the fiber will collect noise with nothing to record or store.
β
Most NeoCloud providers protect inter-site AI traffic with encryption applied above the transport, using MACsec, IPsec, or TLS. Those controls scramble the data and leave the optical signal carrying it intact on the fiber, available to anyone who can physically reach the cable. An operator running a link between a rural GPU campus and a customer on another continent depends on hundreds of kilometres of fiber path it doesn't own and never inspects. The vulnerability this opens is about the harvest rather than the decryption. Bringing the necessity for a security control that hides the signal itself alongside encryption on a remote span.
β
The assets on a GPU interconnect
Model weights are the trained output of a run that can cost hundreds of millions of dollars in compute. They cross the network alongside the training corpora, checkpoints, and inference traffic that produced them. Those transfers move between training clusters, storage tiers, and the customer networks renting the capacity. RAND's May 2024 report, Securing AI Model Weights, catalogues 38 attack vectors against those assets and sorts adversaries from opportunistic criminals up to resourced nation-state operators. The spread across that list is what makes the interconnect a hard problem, because the same file draws both a smash-and-grab attacker and a state program willing to spend years stealthily extracting it.
The attack profile of interception in a WAN is distinct from a data center. Traffic inside a single data hall crosses a LAN the operator controls end to end, with its own guards, cameras, and cable trays. Traffic between a Missouri campus and a customer in Frankfurt crosses carrier fiber, third-party conduit, and ground the operator has never walked. The security model changes at that boundary, since everything past it rests on someone else's physical control of the cable.
Power availability, not network design, decides where GPU capacity gets built. A single campus can draw hundreds of megawatts, and the places that can supply it are rural sites with cheap land and spare power generation rather than the metro areas where fiber is dense. Nebius has set a target of more than 3 GW of contracted power by the end of 2026, anchored by a 1 GW campus in Missouri and a 310 MW facility in Finland. BofA Securities estimates CoreWeave will reach roughly 1.7 GW of active capacity over the same period. Each of those sites still needs a fiber path back to the customers renting the capacity, and that path runs for hundreds of kilometres through ground the operator does not control.
β
Reaching the signal on a remote span
Physical access to a NeoCloud link is easiest at the isolated campus itself and along the transit path between sites. Fiber junction boxes, backup power, and a cooling plant at a remote site sit outside routine foot traffic, so tampering can persist between inspections rather than being caught within minutes. The transit path is even less monitored, with fiber running alongside pipelines, rail corridors, and industrial land for hundreds of kilometres. What both locations give an attacker is time. And time is the difference between a rushed tap and one that is installed properly and left running.
β
A tap at any point does not require cutting the line. Bending a fiber past a certain radius pushes light out through the cladding, where a detector collects it. The optical loss that shows up at the receiver is small enough to sit inside normal variation levels. Therefore, monitoring reads it as ordinary fluctuation and data continues to be exfiltrated. Nothing in the operator's telemetry marks the moment the data started leaking.
β
Why recorded ciphertext is worth storing
An adversary recording an encrypted link today is betting on a decryption capability that does not exist yet. Harvest-Now-Decrypt-Later (HNDL) works by copying the encrypted traffic together with the key exchange that established its encryption, then storing both until that key exchange can be broken. Quantum computers break the key exchange outright. They also weaken the encryption protecting the payload, though less severely, cutting its effective strength without breaking it. One recovered key opens every hour of traffic encrypted under it, not a single message. A checkpoint copied in 2026 costs almost nothing to store, and its contents become readable the moment that key falls, whether that happens in 2030, or soon after.
Data is compromised the moment it is harvested, not when it is finally decrypted. The operator sees nothing change, because the link keeps running, the telemetry stays clean, and the traffic arrives as expected. None of this leaves any indicators of compromise, and once the copy sits in someone else's storage, no control deployed later can undo the exposure. The date a link comes under protection is the boundary of what stays exposed, and every hour before it is vulnerable to compromise.
β
Regulatory Implications
Executive Order 14412, signed June 22, 2026, gives federal agencies who possess high-value assets until December 31, 2030 for post-quantum key establishment and December 31, 2031 for digital signatures, with FAR contractor compliance targeting the same 2030 date. Those are completion deadlines rather than start dates. Traffic crossing the network between now and then travels under the algorithms being retired. Anything recorded during that window stays recorded, whatever encryption algorithm the network is running by the time the deadline arrives.
If a tap leaves no trace, can it be caught at all? Can Fiber Optic Cables Be Tapped, and How Do Enterprises Detect It? covers the detection methods available and where they fall short.
β
Scoping Carmel on a GPU interconnect
Carmel's uplink runs at 100 - 400 Gb/s. A provider aggregating GPU fabric above this range protects it across multiple wavelengths rather than on a single link. Deployment is therefore sized by how much bandwidth needs protecting on each span, not by the number of sites it runs.
Carmel and post-quantum cryptography protect different layers of the same link, which is what lets them work together. A PQC migration replaces the vulnerable key exchange in software, and that program has to run across applications, key management, and third-party dependencies over a span of years. Carmel works beneath all of it at the optical layer, removing the recordable signal rather than the readability of its contents. An operator running both keeps traffic covered on the fiber throughout the transfer and keeps the key exchange covered once the transfer completes. Defense in depth on an interconnect means neither layer depends on the other holding.
β
Carmel on a data center interconnect
Carmel is a Layer 1 optical transmission platform that spreads the signal across a wide spectral band, encodes its phase, and runs the link at a negative signal-to-noise ratio. Our optical spectrum analyser traces show no observable peak on a protected link. The table below applies controls a NeoCloud infrastructure team is more likely to have in place.
β
What to check before protecting a link
The work starts with the cryptography already running across the estate. An operator records which key exchange and payload algorithms protect each inter-site link, then marks the ones due for replacement under the post-quantum deadlines. That inventory points to the spans worth protecting first, which are the ones carrying weights, checkpoints, or customer training data under algorithms that will not hold. Each of those spans then needs a secrecy lifetime for the data crossing it, along with a walk of its physical path for segments where access is easy and inspection is rare. The propagation budget decides the rest, since a remote site can put a span beyond the reach of a control regardless of how sensitive its traffic is.
β
β
FAQs
Q: Does Carmel add latency to a data center interconnect link?
A: There is no added latency for Carmel. Processing happens optically at Layer 1 with no packet overhead, so nothing is added on top of the propagation time the fiber already imposes. The distance penalty of a remote site does not go away, and Carmel does not increase it.
Q: What line rate does Carmel support on a GPU interconnect today?
A: Carmel's uplink runs at 100 Gb/s with a QSFP-28 service port and a 100 GbE service protocol.Β
Q: Can AI model weights be taken from a fiber link without breaking the encryption?
A: The encrypted traffic can be copied off the fiber intact and stored. Breaking it comes later, once the key exchange protecting it can be undermined. This is the gap Carmel addresses, since a tap on a Carmel-protected link captures optical noise and leaves no stored ciphertext to work on afterward.
Q: Does Carmel replace a post-quantum cryptography migration?
A: No. Carmel is complementary to PQC, operating at Layer 1 while post-quantum algorithms operate on the digital layer. The migration still has to run across applications, key management, and third parties. Carmel protects traffic on the link during the years that work takes.
Q: Does Carmel work with the DWDM equipment already on a leased span?
A: Carmel works with existing fiber, requires no modification to existing DWDM equipment, and coexists with other vendors' optical transport.Β
Q: How far can a Carmel-protected link run between GPU sites?
A: Up to 100 km unamplified, with full compatibility with EDFA and Raman amplification for longer spans. That removes the roughly 100 km ceiling that constrains QKD, which cannot pass through in-line amplifiers at all.
Q: What does Carmel do about traffic recorded before it was installed?
A: Nothing, and no product can. Carmel's coverage begins at the point of deployment on a given link. We deploy in a phased sequence measured in weeks, which is the argument for starting on the highest-sensitivity spans first rather than waiting for a migration program to finish.
β