Security in Distributed AI

"I averaged in every gradient I was handed, exactly as instructed. Nobody told me some of the hands belonged to the adversary."

A Worker Node, Trusting Every Gradient It Receives, Perhaps Too Much

Reliability, the subject of the sections before this one, assumes that components fail independently and without intent: a node dies, a link drops packets, a disk fills, and none of these events is trying to deceive you. Security removes that comfort. An adversary chooses which component to compromise, observes how your system reacts, and crafts inputs designed to defeat the very mechanisms you built for reliability. The same averaging step that makes data-parallel training exact in Chapter 1 becomes a liability when one of the values being averaged was chosen by an attacker to drag the result wherever it likes. Moving from reliability to security is the move from "what can break by accident?" to "what can be broken on purpose?", and at scale the answer involves far more components than any honest fleet would ever fail at once.

The scale-out tie is direct and unavoidable. A federated learning round (Chapter 14) aggregates updates from thousands of phones the operator has never seen and cannot audit; a multi-tenant cluster runs jobs from mutually distrustful teams on shared hardware; an edge deployment (Section 34.9) ships model weights to devices that are physically in the hands of users, some of whom are adversaries. In every case the system must produce a correct result while trusting parties it does not control. Security in distributed AI is therefore not an add-on; it is a consequence of the same decision to distribute that the whole book is about.

1. The Attack Surface Grows with the Cluster Beginner

On a single machine, the boundary between "inside the system" and "outside" is a single process on a single host. The data, the model, the gradients, and the predictions all live behind one operating-system boundary, and an attacker must breach that one boundary to touch any of them. Distribution shatters this neat picture. The data now flows across a network to many workers; the gradients travel back to a parameter server or around an all-reduce ring (Chapter 11); the model is sharded across devices that may sit in different racks, datacenters, or organizations; and the predictions are served from a fleet behind a load balancer. Each of these flows is a wire an attacker can tap, and each node holding a piece is a host an attacker can compromise.

Figure 35.3.1 maps this surface onto the distributed training-and-serving pipeline. Read it as the inventory of places where confidentiality, integrity, or availability can be attacked: the data path, the gradient or parameter channel, the compute nodes themselves, the shared infrastructure beneath them, and the inference endpoint exposed to the world. The remaining sections of this section walk these regions in turn.

The growth is not merely additive. If a single host is compromised with probability $p$ over the lifetime of a job, then the probability that at least one of $N$ hosts is compromised is $1 - (1-p)^N$, which approaches one as $N$ grows. The very scale that buys throughput also raises the chance that some participant is hostile, and in the federated and decentralized settings of Chapter 14 a fraction of participants may be adversarial by assumption rather than by accident. We therefore parameterize the threat by the fraction of malicious nodes $f/N$, exactly as the Byzantine fault model of Chapter 2 parameterized arbitrary failures, and ask how large that fraction can grow before the system's guarantees break.

2. Confidentiality, Integrity, Availability, Mapped to AI Assets Beginner

Classical security organizes threats along three axes, the so-called CIA triad: confidentiality (only authorized parties can read an asset), integrity (only authorized parties can change it), and availability (authorized parties can use it when needed). The triad is generic, but it becomes a precise checklist once we map it onto the four assets a distributed AI system actually holds: the training data, the model weights, the gradients or updates in flight, and the predictions served to clients. Table 35.3.1 carries out that mapping and names the representative attack in each cell, which is the structure the rest of this section follows.

Two cells deserve emphasis because they are distinctive to distributed AI rather than inherited from generic systems security. First, the confidentiality of gradients: a value that looks like an anonymous vector of numbers can, with enough effort, be inverted to reconstruct the private training examples that produced it, which is why secure aggregation and differential privacy (introduced in Chapter 14 and revisited later in this chapter) protect the update channel even when no single update is itself sensitive. Second, the integrity of gradients: because training averages updates from many sources, an attacker who controls even one source can move the average, which is the precise vulnerability that Byzantine-robust aggregation in Section 35.5 exists to close. The runnable demonstration in Section 5 makes this second point concrete.

3. Threat Classes: Training Time, Inference Time, Infrastructure Intermediate

The cells of Table 35.3.1 cluster naturally into three threat classes by when in the system's life they strike. Training-time attacks corrupt the model while it is being built. Inference-time attacks target the finished model as it serves. Infrastructure attacks compromise the machinery underneath both. Keeping the three classes distinct matters because they call for different defenses deployed at different stages, and because a single adversary often chains them: a supply-chain foothold (infrastructure) used to plant a backdoor (training time) that is later triggered by a crafted input (inference time).

Training-time attacks exploit the fact that a learner trusts its data and its peers. In data poisoning, the attacker injects or relabels training examples so the learned model misbehaves; in a backdoor (or trojan) attack, the poison is crafted so the model behaves normally except on inputs carrying a secret trigger, at which point it produces an attacker-chosen output. These are the central subject of Section 35.4. In the distributed setting they are amplified: a poisoner does not need to corrupt a central dataset, it merely needs to be one of the many participants whose updates are aggregated, which is why federated learning makes poisoning both easier to mount and harder to detect. The fraction of poisoned data or malicious participants, again $f/N$, is the attacker's budget, and a defense is meaningful only relative to a stated bound on it.

Inference-time attacks leave the model unchanged and instead exploit the trained model through its public interface. Three matter most. Adversarial examples (evasion) are inputs perturbed by a small, often imperceptible amount $\delta$ with $\lVert \delta \rVert \le \epsilon$ that nonetheless flip the model's prediction, so the attacker controls the output without touching the weights. Model extraction (stealing) queries the endpoint enough times to train a surrogate that replicates the target's behavior, stealing the intellectual property embodied in the weights through the prediction channel alone. Membership inference asks, of a specific record, whether it was in the training set, a confidentiality breach that matters acutely for models trained on medical or personal data (Chapter 14). All three are sharpened by distribution: a model replicated across a public-facing fleet offers the attacker many endpoints and high query throughput.

Infrastructure attacks ignore the AI semantics entirely and go after the systems substrate, where distribution does the most damage because the substrate is shared. A compromised worker can report fabricated gradients or read every shard that passes through it. A man-in-the-middle on the parameter channel (Chapter 11) can read updates in flight (a confidentiality break) or alter them (an integrity break) unless the channel is authenticated and encrypted. A supply-chain compromise, a poisoned dependency, a backdoored container image, or a tampered model in the registry, reaches every node that pulls it, turning one corrupted artifact into a fleet-wide breach. The purple band in Figure 35.3.1 is exactly this layer, and its reach across every box above is why it is the highest-leverage target an adversary has.

4. Defenses: From Encrypted Channels to Robust Aggregation Intermediate

The defenses pair with the threat classes, and it is useful to see them as layers rather than as a single switch. At the channel layer, authentication and encryption (mutual TLS between workers and the aggregator, signed model artifacts in the registry) close the man-in-the-middle and supply-chain integrity gaps; they ensure that a message came from who it claims and was not altered, which is the baseline every distributed-training deployment should already have. At the execution layer, trusted execution environments (hardware enclaves such as confidential-computing VMs and GPUs) let a node prove it ran the agreed code on the agreed data, shrinking the trust placed in a co-tenant or a cloud operator. At the data layer, differential privacy bounds how much any single record can influence the model, defeating membership inference and gradient reconstruction by adding calibrated noise, at a measured cost in accuracy.

The layer this chapter studies most closely is the aggregation layer, because it is where the distinctive AI vulnerability lives. When training averages updates from many sources, the mean is the least robust statistic imaginable: a single value sent to $\pm\infty$ drags the average there too. Anomaly detection can flag updates whose norm or direction departs sharply from the consensus, and robust aggregation replaces the mean with an estimator that a bounded minority cannot move, such as a coordinate-wise median, a trimmed mean, or a geometric-median rule. These are the Byzantine-robust aggregators of Section 35.5, and they are the direct security descendant of the fault-tolerant aggregation lineage that runs from the Byzantine model in Chapter 2 through elastic training to here. The demonstration below shows why the mean fails and why a trimmed estimator survives, motivating the full treatment in the next section.

# Plain federated averaging is one strategy ...
from flwr.server.strategy import FedAvg, FedTrimmedAvg

# ... and a Byzantine-robust trimmed mean is a drop-in replacement.
strategy = FedTrimmedAvg(beta=0.1)   # trim 10% of updates per coordinate
# server.fit(strategy=strategy)      # secure transport + robustness, handled internally

5. Why the Mean Is Not Safe: A Single Update Captures the Average Intermediate

The clearest way to feel the integrity problem is to watch one malicious update capture the aggregate. The script below has $N = 32$ nodes report a gradient. Twenty-nine are honest and report noisy copies of the same true gradient whose first coordinate points clearly positive; three are malicious and send a large update aimed in the opposite direction. We then compute the plain average over all $N$ nodes, the answer we actually want (the honest mean), and a trimmed mean that drops the $f$ largest and smallest values per coordinate before averaging. Finally we sweep the number of attackers to find how few it takes to flip the sign of the aggregated gradient's first coordinate.

import numpy as np

rng = np.random.default_rng(7)
N, d = 32, 20                 # N nodes report a gradient of dimension d
f = 3                         # f of them are malicious

# Honest nodes report noisy copies of the same true gradient whose first
# coordinate points clearly in the positive direction.
g_true = rng.standard_normal(d); g_true[0] = 1.0
honest = g_true + 0.15 * rng.standard_normal((N - f, d))

# Malicious nodes send a large, coordinated update aimed the opposite way.
attack_dir = np.zeros(d); attack_dir[0] = 1.0
malicious = -40.0 * attack_dir + 0.15 * rng.standard_normal((f, d))

reports = np.vstack([honest, malicious])
honest_mean = honest.mean(axis=0)             # the answer we WANT
naive_mean = reports.mean(axis=0)             # plain average over all N

# Trimmed mean: drop the f largest and f smallest per coordinate, then average.
srt = np.sort(reports, axis=0)
trimmed = srt[f:N - f].mean(axis=0)

dist = lambda a, b: float(np.linalg.norm(a - b))
print(f"nodes N                 : {N}   (malicious f = {f}, fraction = {f/N:.3f})")
print(f"||naive_mean - honest|| : {dist(naive_mean, honest_mean):.3f}")
print(f"||trimmed    - honest|| : {dist(trimmed, honest_mean):.3f}")
print(f"naive_mean[0]           : {naive_mean[0]:+.3f}   (honest target {honest_mean[0]:+.3f})")
print(f"trimmed[0]              : {trimmed[0]:+.3f}")
print()
for k in range(0, 9):         # how few attackers flip the sign of mean[0]?
    mix = np.vstack([honest, np.tile(-40.0 * attack_dir, (k, 1))])
    m = mix.mean(axis=0)[0]
    flag = "  <-- mean[0] now points the wrong way" if m < 0 else ""
    print(f"  f={k}: naive mean[0] = {m:+.3f}{flag}")

nodes N                 : 32   (malicious f = 3, fraction = 0.094)
||naive_mean - honest|| : 3.865
||trimmed    - honest|| : 0.108
naive_mean[0]           : -2.867   (honest target +0.981)
trimmed[0]              : +0.960

  f=0: naive mean[0] = +0.981
  f=1: naive mean[0] = -0.385  <-- mean[0] now points the wrong way
  f=2: naive mean[0] = -1.663  <-- mean[0] now points the wrong way
  f=3: naive mean[0] = -2.861  <-- mean[0] now points the wrong way
  f=4: naive mean[0] = -3.986  <-- mean[0] now points the wrong way
  f=5: naive mean[0] = -5.045  <-- mean[0] now points the wrong way
  f=6: naive mean[0] = -6.044  <-- mean[0] now points the wrong way
  f=7: naive mean[0] = -6.987  <-- mean[0] now points the wrong way
  f=8: naive mean[0] = -7.879  <-- mean[0] now points the wrong way

The number worth dwelling on is that one attacker out of thirty-two flips the sign of the gradient that the whole training step will follow. The honest fleet wanted to move the parameter in one direction; a single adversary sending an unbounded update made it move in the other. The trimmed mean resists because it discards the extremes before averaging, so a bounded minority cannot reach the surviving samples, and it returns within rounding distance of the honest answer. This is the entire argument for Byzantine-robust aggregation, made on twenty lines of code: when you average values you do not control, the mean is an attack vector, and the fix is to replace it with an estimator whose breakdown point exceeds the adversary's budget $f/N$. Section 35.5 turns this observation into named algorithms with provable guarantees.

6. GPU Confidential Computing and Attestation Advanced

The defenses surveyed in section 4 close channel-level and aggregation-level gaps, but they share a structural limitation: they trust the host operating system and the hypervisor. A cloud operator who can inspect kernel memory or freeze and copy a VM's RAM breaks the confidentiality of model weights and training data regardless of how well those assets were encrypted in transit. Cold-boot attacks against unencrypted GPU VRAM, exploited by a malicious co-tenant or a privileged insider, let an adversary extract multi-billion-parameter weights without ever touching the network. This threat class sits beneath the software stack: it is not a protocol vulnerability but a hardware-boundary violation. The distributed-systems consequence is direct. When a federated learning server, a multi-tenant training cluster, or a confidential inference endpoint runs in the cloud, the cloud operator is simultaneously a service provider and a potential adversary of the organizations that own the data and the model. Contractual guarantees help, but they are not technical ones. Hardware-backed Trusted Execution Environments (TEEs) close that gap by giving a distributed AI workload a cryptographic proof that its code runs on genuine, unmodified hardware and that its memory is encrypted even from the host.

6.1 Why Software Isolation Is Insufficient

A hypervisor virtualizes CPU, memory, and I/O between co-tenants, but the hypervisor itself runs in a higher privilege ring and can read any guest's physical memory pages. An OS kernel can dump any process's address space. Neither of these attacks requires network access; both are available to an insider at the cloud provider or to an attacker who has compromised the hypervisor via a kernel exploit. The problem is especially acute for GPU memory. VRAM is large, monolithic, and historically unencrypted: a driver restart or a direct hardware read after a job finishes can expose hundreds of gigabytes of model weights or activations. Three concrete threat scenarios motivate the hardware fix:

• Hypervisor inspection. A cloud operator (or an attacker who has compromised the privileged control plane) can map a guest's physical memory, copy it, and reconstruct model weights or training batches without any network trace.
• Cold-boot and device reset attacks. After a GPU job ends, VRAM retains its contents for hundreds of milliseconds; a subsequent tenant or a physical-access attacker can read the residue. Large language models, whose weights fill an H100 entirely, are the highest-value target.
• Multi-tenant side channels. Shared GPU hardware exposes timing and power side channels. When co-tenants share a device's SM scheduling, an attacker can infer memory-access patterns of the victim's model, leaking information about the architecture or the data.

Software-only countermeasures (seccomp filters, namespace isolation, encrypted disk images) address the network and filesystem layers but leave VRAM and RAM unencrypted during execution, which is precisely when the data has the most value. The hardware solution encrypts memory in-place and roots trust in the silicon rather than in the software stack above it.

6.2 NVIDIA Confidential Computing Mode

NVIDIA Confidential Computing (CC) mode, available on H100, H200, B200, and GB200 GPUs, encrypts VRAM with AES-256 and makes the GPU a hardware-rooted attestation authority whose claims cannot be forged in software. Three mechanisms work together, as illustrated in Figure 35.3.2.

The three mechanisms deserve precise description. First, AES-256 VRAM encryption: the H100's memory controller sits inline on the VRAM bus and encrypts every cache-line write and decrypts every read with a session key that lives exclusively inside the GPU die. The key is never exposed on the PCIe bus, never visible to the host driver, and never retained across a reset. Any physical or software read of VRAM outside the GPU's own logic returns ciphertext. Second, GPU-to-host PCIe encryption: data moving between the GPU and the CPU over PCIe is separately encrypted via the GPU Direct RDMA encryption path, so neither the host memory controller nor a DMA snooper on the PCIe fabric sees plaintext. Third, firmware measurement and attestation: the GPU's RoT (Root of Trust) measures its own firmware at boot, signs the measurement with the DeviceRoot CA private key, and produces an attestation report that includes the firmware hash, the current CC mode configuration, and a nonce from the relying party. Because the signing key is fused into silicon at manufacture, the report cannot be forged by any software on the host.

6.3 The Attestation Flow

The attestation handshake is the cryptographic backbone of confidential computing: it gives the relying party (the model owner, the data regulator, or an automated provisioning service) a machine-verifiable proof that the GPU it is about to trust is genuine, running known-good firmware, and in CC mode before any sensitive asset enters the protected enclave. The flow has three logical stages, described below and sketched in the pseudocode in Code 35.3.3.

1. GPU generates a signed measurement. The relying party sends a fresh nonce to the GPU. The GPU's RoT hashes its firmware image and the current CC configuration, concatenates the nonce to prevent replay, and signs the result with its DeviceRoot CA private key. The output is an attestation evidence blob (in NVIDIA's format, a SPDM-over-PCIe Get Measurements response) that the host driver forwards to the relying party without being able to alter it.
2. Relying party verifies the signature chain. The relying party fetches or caches NVIDIA's certificate chain (DeviceRoot CA to Group Device Certificate to Device Identity Certificate) and checks that the signature on the evidence was produced by the device certificate, that the device certificate chains to NVIDIA's published root, and that none of the certificates are revoked (queried via NVIDIA's OCSP service). If the firmware hash in the evidence matches a known-good reference value, the device is considered trustworthy.
3. Provisioning into encrypted VRAM. Only after a successful attestation does the relying party release the model weights, the decryption key for the training dataset, or any other sensitive asset. The provisioning uses a session key established during the attestation exchange, so the weights travel over an end-to-end encrypted channel from the relying party's store directly into the GPU's encrypted VRAM. At no point does the cloud operator's OS or hypervisor see the weights in plaintext.

The Python pseudocode below sketches the relying-party side of steps 1 through 3 using NVIDIA's nv-attestation-sdk, which wraps the SPDM measurements and OCSP verification into a small API. A production deployment would call this from a key-management service that holds the model weights and releases them only to verified devices.

"""
Relying-party attestation pseudocode using NVIDIA nv-attestation-sdk.
Real imports: pip install nv-attestation-sdk
This pseudocode shows the structure; consult the SDK docs for exact method
signatures and the NVIDIA OCSP endpoint for production certificate chains.
"""

import nv_attestation_sdk as nv_attest
import secrets

# ── Step 1: Generate a nonce and request GPU evidence ────────────────────────
relying_party_nonce = secrets.token_bytes(32)   # fresh for every session

# In a real deployment, the GPU driver forwards this request to the GPU RoT
# over the SPDM-over-PCIe channel.
gpu_evidence = nv_attest.request_evidence(
    device_id="gpu:0",         # target GPU
    nonce=relying_party_nonce, # anti-replay
)
# gpu_evidence contains: firmware_hash, cc_mode_flags, nonce_echo, signature

# ── Step 2: Verify the certificate chain and the signature ───────────────────
cert_chain = nv_attest.fetch_cert_chain(
    ocsp_url="https://ocsp.ndis.nvidia.com/",
    device_cert_id=gpu_evidence.device_cert_id,
)

validation_result = nv_attest.verify(
    evidence=gpu_evidence,
    cert_chain=cert_chain,
    trusted_root_ca=nv_attest.NVIDIA_ROOT_CA,   # pinned at build time
    expected_firmware_hashes=APPROVED_FIRMWARE,  # operator policy
)

if not validation_result.passed:
    raise RuntimeError(
        f"Attestation failed: {validation_result.reason}. "
        "Refusing to provision model weights."
    )

# ── Step 3: Provision model weights into encrypted VRAM ─────────────────────
session_key = validation_result.session_key     # derived during SPDM exchange

encrypted_weights_path = "s3://model-weights/llm-7b-confidential.bin.enc"
nv_attest.provision_weights(
    device_id="gpu:0",
    weights_uri=encrypted_weights_path,
    session_key=session_key,   # end-to-end; host never sees plaintext weights
)

print("Attestation passed. Model weights provisioned into encrypted VRAM.")
print(f"  Firmware hash : {gpu_evidence.firmware_hash.hex()}")
print(f"  CC mode flags : {gpu_evidence.cc_mode_flags}")
print(f"  Device cert   : {gpu_evidence.device_cert_id}")

6.4 Current Limitations

Confidential Computing mode is production-ready for single-GPU workloads on H100 and H200 but carries several constraints that matter for large distributed AI jobs, and a performance overhead that must be budgeted.

Multi-GPU CC maturity. NVLink, the high-bandwidth interconnect between GPUs in a node, is not yet encrypted in CC mode on H100 or H200 in most cloud configurations. An attacker who can snoop the NVLink fabric sees plaintext activations and gradients moving between GPUs within the same node, partially undermining the per-GPU VRAM encryption. Full NVLink encryption for multi-GPU CC requires the GB200 NVL72 system, where NVIDIA has implemented NVLink-encrypted multi-GPU communication. Until GB200 NVL72 systems are widely available, large-scale training that uses tensor parallelism across many GPUs in a single node cannot yet provide an end-to-end confidential guarantee on all communication paths.

Profiling and observability restrictions. CC mode disables several NVML performance counters, fine-grained SM utilization metrics, and hardware performance events that profilers such as Nsight Compute rely on. The encryption of VRAM and the hardware isolation make it impossible to inspect memory contents or instruction traces without breaking the confidentiality guarantee, so the tooling that distributed AI practitioners use to diagnose throughput bottlenecks is unavailable inside a CC enclave. Teams that run CC in production must profile in a non-CC environment and then deploy into CC without the ability to repeat the profiling pass.

Throughput overhead. The AES-256 inline encryption engine is fast but not free. Measured on H100 with typical training workloads, CC mode incurs a throughput penalty in the range of 5 to 10 percent compared to standard mode, primarily due to memory bandwidth overhead from encryption and the SPDM attestation latency at job startup. For inference endpoints serving latency-sensitive traffic, this overhead must be weighed against the confidentiality benefit. For long-running training jobs where the startup cost amortizes and the memory-bandwidth penalty is partially hidden by compute, the overhead is typically acceptable.

6.5 Composite Attestation: Intel TDX and NVIDIA CC

A single-GPU TEE protects the compute side but leaves the path between the CPU and the GPU as a gap if the CPU itself is not protected. In a standard cloud VM, the CPU-side OS and hypervisor can observe the application code, the data loaded from storage, and the results returned from the GPU, even if VRAM is encrypted. End-to-end confidential ML pipelines therefore stack two TEEs: a CPU TEE and a GPU TEE, so neither the model weights nor the training data are visible to the cloud operator at any point in the pipeline.

The most widely deployed pairing is Intel TDX (Trust Domain Extensions) for the CPU side with NVIDIA Confidential Computing for the GPU side. Intel TDX creates a hardware-isolated Trust Domain at the CPU level, encrypting the guest VM's RAM with a key held in the CPU's multi-key total memory encryption (MKTME) engine and producing a TDX attestation report signed by an Intel-fused key. The composite attestation flow extends Code 35.3.3: the relying party must verify both the TDX report (proving the CPU guest is running the agreed code in an encrypted trust domain) and the NVIDIA CC report (proving the GPU is genuine and in CC mode) before provisioning any asset. The two reports are linked by a binding nonce so the relying party can confirm they describe the same compute job. Once both attestations pass, the model weights can flow from the relying party's key-management service through the encrypted PCIe bus into the GPU's encrypted VRAM, with the CPU-side application code never able to read them in plaintext either. The result is a pipeline where every memory boundary from storage to compute is encrypted and every compute stage has a hardware-rooted proof of integrity, satisfying the strictest interpretation of a confidential ML workload.