Network taps copy the traffic on a data centre's cables.
In verification proposals, a tap or "secure gateway" hashes everything entering and leaving a cluster. The verifier later asks the operator to reveal randomly chosen records, which are recomputed and checked. The aim is to show that outputs came from declared work, and that results of undeclared work cannot leave covertly through tapped links.
Designs, cost estimates and covert-channel analyses are public. Amodo's tests have copied traffic from 1–10 Gbps links without hashing it. As of September 2026 no tap has been demonstrated at production link rates or red-teamed.
The main obstacles are hashing small frames at full speed on 400-gigabit-class links, and tapping copper or encrypted cluster networks. The largest known weakness is covert signalling in model outputs: one design's benign-prompt extrapolation gives about 40 Mbit/s for a 200,000-GPU inference cluster, even with replay checks, unless inference becomes deterministic.
On this page
How it works
A network tap is a device that "mirror[s] network traffic without disrupting normal operation" 2. Verification proposals use taps to build a record of what crossed a link, which the verifier can check later 2 3. The MIRI system overview states the principle as "capture everything, challenge and audit random samples after" 3.
In the most detailed designs, the verifier never receives plaintext 1 3. The tap hashes payloads over groups of packets, without knowing where objects such as prompts begin or end, and sends only hashes out; the operator (the prover) keeps the plaintext 1 3. Later the verifier picks stored hashes at random, the prover supplies the matching data, and a verification facility replays the computation and checks that the hashes match 1. The prover fails the challenge if it supplies no data, or data that does not match the stored hash 3. A replay that does not reproduce the recorded output points to false metadata, a technical fault or a workload other than the one declared 3.
The AI 2040 plan proposes a simpler variant: passive taps on the frontend network copy all input and output traffic to a recomputation server (Sampled inference recomputation, Whole-workload recomputation (reproducible packets)) 4.
Taps can sit at three levels 2:
- North-south (frontend) links to the outside world, at an estimated material cost under 0.01% of the monitored data centre 2.
- The storage fabric, which carries model loads, dataset reads and checkpoint saves, at an estimated 0.3–0.5% of data-centre cost 2.
- The compute (east-west) fabric, at an estimated 0.2–1.5% of data-centre cost for its optical levels. Volumes there are so high that Cankaya proposes sampling, for example 0.01% of traffic, about 20 Gb/s, through an optical circuit switch 2.
For inference, the monitored perimeter could be as small as pods of a few hundred accelerators; monitoring training needs larger perimeters or taps on the compute and storage fabrics 3.
A key aim of the "Secure Gateway Device" design is that no processor has to be trusted by both sides 1. It uses passive optical splitters, so that each party can watch the signals it must check, and coin-flip protocols to generate shared random values 1. It also acts as an "active warden", rewriting free header fields and re-timing packets to close timing, analogue and header channels that checks on hashes cannot address 1.
SASH's planned next prototype would place an FPGA between the cluster and its gateway to issue "cryptographic certificates attesting to the encrypted traffic it has seen" 12; see SASH confidential network logger.
What it establishes
The Secure Gateway Device paper aims to make it "infeasible to covertly exfiltrate the results of undisclosed workloads in the cluster through the tapped wires" 1. Combined with replay, it would show that recorded outputs match declared workloads 1 4; see inference-only use and weight exfiltration.
It does not establish:
- Taps capture flows, not device state, and the MIRI system overview treats memory probes as complementary 3.
- A north-south tap does not directly prevent covert workloads, only the exfiltration of their results 1. The paper judges it futile to block every single-bit leak. It argues that the residual risk, covert computation plus low-bandwidth signalling of results, needs other checks such as east-west taps and throughput accounting 1.
- The paper does not decide which workloads should be allowed, or whether declared workloads comply 1.
Threat model
- The operator and the verifier distrust each other. The operator must not hide information in the traffic, and the verifier must learn nothing beyond hashes 1.
- The facility is physically monitored, so that all traffic passes through the gateway 1.
- The operator stores all hashed data for the agreement's duration 1.
- Replay needs reproducible inference (Deterministic and bit-exact inference) 1 3.
- The MIRI system overview models a covert adversary, deterred when the likelihood of detection times the cost of being caught exceeds the expected gain 3.
Implementations
AI 2040 inference-only verification stack
A proposed retrofit that splits data centres into isolated inference units, copies front-end traffic and re-runs random samples to confirm only declared inference runs.
Proposed for showing that retrofitted data centres run only inference
Low-trust AI compute verification system overview
A reference design that existing data centres could add: network taps hash all traffic, and air-gapped, independently sourced checkers later re-run randomly chosen records.
Proposed for screening challenged records to show declared inference compute is not training
SASH confidential network logger
An open-source prototype that routes a facility's inference traffic through a logger and re-runs requests on a separate cluster to check the facility serves inference.
Proposed for telling inference from training on a mutually inspected cluster