Encryption keeps AI data unreadable in transit. It does not keep it from being recorded. Here is how each available control handles the long WAN spans between remote GPU campuses.
Traffic between NeoCloud GPU sites is typically encrypted, but the optical signal can still be tapped and stored for later decryption. Transport encryption, post-quantum cryptography, and quantum key distribution each protect part of the link. Only a physical-layer control removes the recordable signal itself, and it works best alongside post-quantum migration rather than in place of it.
The siting problem behind the security problem
GPU capacity goes where the power is. One campus can draw hundreds of megawatts, and that supply sits in rural areas with cheap land and spare generation, not in metro fiber hubs.
The scale is significant:
- 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.
- CoreWeave is estimated by BofA Securities to reach roughly 1.7 GW of active capacity over the same period.
- Lambda and other NeoCloud providers follow the same power-first siting logic.
Every site needs a fiber path back to the customers renting it. That path is a wide-area network (WAN) link, often leased, frequently running for hundreds of kilometres through ground the operator never inspects. The scope here is data in transit on those WAN spans, not traffic inside a single building.
What is at stake on a GPU interconnect
Four types of data cross these links:
- Model weights, the output of training runs that can cost hundreds of millions of dollars in compute.
- Training corpora, the source data behind those weights.
- Checkpoints, intermediate training states that can be resumed or reverse-engineered.
- Inference traffic, live customer requests and responses.
RAND’s 2024 report on securing AI model weights catalogues 38 attack vectors against these assets and grades adversaries from opportunistic criminals to resourced nation-state programs. The range is the point: the same file attracts both a smash-and-grab attempt and a multi-year collection effort.
Where the threat model shifts
| Environment | Who controls the fiber | Physical monitoring | Exposure to tapping |
|---|---|---|---|
| Inside a single data hall (LAN) | The operator | Guards, cameras, locked trays | Low |
| Remote campus perimeter | The operator, lightly staffed | Periodic inspection | Moderate |
| Inter-site transit route (WAN) | Carriers and third parties | Minimal to none | High |
Two points on the WAN stand out. At the remote campus, junction boxes, backup power, and cooling plant see little routine foot traffic, so tampering can persist between inspections. Along the transit route, fiber follows pipelines, rail corridors, and industrial land for long stretches with almost no oversight. Both give an attacker the one thing that separates a rushed tap from a well-installed one: time.
How the tap itself works
No cut is required. Bending fiber past a critical radius pushes light out through the cladding, where a detector collects it. The optical loss at the receiver falls inside normal variation, so monitoring reads it as ordinary fluctuation. Traffic keeps flowing, telemetry stays clean, and there is no indicator of compromise.
Why recorded ciphertext still matters
Harvest Now, Decrypt Later (HNDL) is the reason an attacker bothers to record traffic they cannot yet read:
- Copy the encrypted traffic and the key exchange that set it up.
- Store both. Storage is cheap.
- Wait until the key exchange (RSA, ECDH) can be broken, most likely by a future quantum computer.
- Recover the session key and read every hour of traffic encrypted under it.
The payload cipher, usually AES-256, is considered quantum-resistant. The exposure sits in the key exchange. The data is effectively compromised at step one, and no control deployed afterward can reverse that.
The regulatory clock. Executive Order 14412, signed June 22, 2026, gives federal agencies holding high-value assets until December 31, 2030 for post-quantum key establishment and December 31, 2031 for digital signatures, with federal contractors on the same 2030 target. These are completion deadlines. Traffic recorded before migration finishes stays recorded under the old algorithms.
The controls, compared
The table below compares the controls a NeoCloud infrastructure team is most likely to have in place or be evaluating, including CyberRidge’s Carmel as the physical-layer option.
| Control | What it protects | Effect on the link | What a fiber tap captures | Fit for remote GPU spans |
|---|---|---|---|---|
| MACsec / IPsec transport encryption | Payload confidentiality | Added processing at each hop | Ciphertext and traffic patterns | Already common; stops reading, not harvesting |
| PQC migration (ML-KEM, ML-DSA) | The key exchange, against future quantum attack | No change to the optical link; larger key exchange payloads at endpoints | Ciphertext | Required under EO 14412 timelines; traffic stays exposed during migration |
| QKD | Key material only | Needs a dedicated fiber or wavelength; no in-line amplifiers | Ciphertext | Roughly 100 km reach rules out most inter-site spans |
| Carmel (photonic layer security) | The transmitted signal itself | No added latency | Optical noise | Runs on existing DWDM; 100 km unamplified, longer with EDFA and Raman amplification |
Read-out: the first three rows all leave a recordable signal on the fiber. They differ in what they protect once that signal is captured. Photonic layer security is the only category here that changes what the tap collects, by spreading the signal across a wide spectral band, encoding its phase, and running the link at a negative signal-to-noise ratio. It does not replace PQC. PQC secures the key exchange for the long term; the physical layer keeps traffic from being harvested in the years before migration completes.
Sizing note. Carmel’s uplink currently runs at 100 Gb/s. A provider aggregating GPU fabric above that protects it across multiple wavelengths, so deployment scales with the bandwidth on each span rather than the number of sites.
Verdict: how to prioritize
A practical sequence for any team running inter-site AI traffic:
- Inventory the cryptography. Record which key exchange and payload algorithms protect each WAN link, and flag those due for replacement under post-quantum deadlines.
- Rank spans by what they carry. Links moving model weights, checkpoints, or customer training data come first.
- Set a secrecy lifetime. Estimate how long the data on each span must remain confidential.
- Walk the route. Identify physical segments where access is easy and inspection is rare.
- Check the distance budget. Span length and amplification decide which controls are even viable on a given link.
The date a link is protected marks the boundary of what remains exposed. Earlier is better on the highest-sensitivity spans.
FAQ
Q: Why are NeoCloud GPU campuses built so far from major networks?
A: Power. A single campus can draw hundreds of megawatts, and that supply is found in rural areas rather than metro fiber hubs.
Q: Can AI model weights be stolen from a fiber link without breaking encryption?
A: Yes. The encrypted traffic can be copied intact and stored. Decryption happens later, once the key exchange protecting it can be broken.
Q: Why is QKD a poor fit for most inter-site GPU links?
A: QKD cannot pass through in-line amplifiers, which limits it to roughly 100 km. Most inter-site spans are longer.
Q: Does Carmel add latency to a data center interconnect?
A: No. Processing happens optically at Layer 1 with no packet overhead, so nothing is added beyond the fiber’s normal propagation time.
Q: How far can a Carmel-protected link run between GPU sites?
A: Up to 100 km unamplified, and further with EDFA and Raman amplification.
Q: Does Carmel replace a post-quantum cryptography migration?
A: No. Carmel works at the physical layer and PQC at the digital layer. Carmel protects traffic on the fiber during the years a PQC migration takes.