{
  "schema_version": "1.0.0",
  "rubric_version": "1.0",
  "license": "CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)",
  "record": {
    "id": "M-0013",
    "slug": "network-taps-and-certifiers",
    "title": "Network taps and certifiers",
    "aliases": [
      "Secure network taps",
      "Cluster I/O fingerprinting",
      "Secure Gateway Device"
    ],
    "status": "draft",
    "last_reviewed": "2026-09-23",
    "review_interval_days": 90,
    "steward": null,
    "provenance": {
      "drafted_by": "ai",
      "reviewed_by": []
    },
    "risk_flags": [],
    "flags": [],
    "one_liner": "Devices on a cluster's network links that copy and hash all traffic, so a verifier can later check sampled records against declared work.",
    "summary": "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 the tapped links. Designs, cost estimates and covert-channel analyses are public. Amodo's small tests have tapped 1–10 Gbps links; as of September 2026 no tap has been demonstrated at production link rates or red-teamed. The main obstacles are hashing at line rate on 400G-class links, and tapping copper or encrypted fabrics. The largest known weakness is covert signalling in model outputs: one design estimates about 40 Mbit/s for a 200,000-GPU inference cluster, even with replay checks, unless inference becomes deterministic.",
    "technical": "Secure Gateway Device (SeGaDev) [[S-1300]]:\n\n- **Placement.** The device sits on the north-south boundary, between TLS termination at the frontend gateway and the internal fabric. If traffic is end-to-end encrypted internally, the device hashes ciphertext and the prover stores session keys [[S-1300]].\n- **Pipeline.** (1) Sanitization by an active warden, which replaces exploitable header fields (ephemeral source ports, TCP initial sequence numbers, session IDs) with pseudorandom values, keeps connection-tracking tables, and releases buffered packets on a fixed schedule to suppress timing and analogue modulation; (2) hashing of a configurable group of packets (the \"hashing boundary\") over payloads only; (3) transmission of hashes alone to the verifier on a dedicated fibre, with a passive splitter giving the prover a copy and a prover-controlled \"timing warden\" re-timing the hash stream [[S-1300]].\n- **Shared randomness and timestamps.** Shared pseudorandom values come from a commit-then-reveal coin flip between prover- and verifier-supplied generators, precomputed in bulk and consumed in FIFO order. Timestamps are taken by both parties on receipt of hashes, not by the tap [[S-1300]] [[S-0018]].\n- **Audit.** The verifier selects stored hashes; the prover returns preimages (prompt, output, token start index, token count) to a verification facility that replays the computation and compares hashes. With k random challenges, a misreported fraction p is detected with probability 1 − (1 − p)^k; k = 3,200 detects 0.1% misreporting at 96% confidence [[S-1300]].\n- **Storage.** A pessimistic upper bound (100k Hopper GPUs at 2,000 tokens/s each, one token per streaming frame) is about 200 PB of SHA-256 hashes and 1,260 PB of prover-held plaintext per year, about €22.5 million in drives [[S-1300]].\n- **Dictionary attacks.** Against verifier dictionary attacks on hashes of short outputs, the paper recommends at least 5 tokens per hashed template, or at least 10 if the attacker filters for likely tokens [[S-1300]].\n- **Residual covert channels.** A 10 ms re-timing window at 100 Gbps holds up to about 625k packets, so packet-count modulation must be fixed per connection per window. Output nondeterminism leaves about 0.1 bit per token even with seed-synchronized replay, which gives about 40 Mbit/s for 200k GPUs at 2,000 tokens/GPU/s. Feigned hardware failures give about 1 kbit/day [[S-1300]].\n- **Line-rate hashing (Amodo).** On an AMD EPYC 9354P with DPDK, all tested algorithms except BLAKE3 reached the receive baseline at 1500-byte frames once enough threads were used; at 64-byte frames none reached line rate within the CPU's physical core count. Offloading to the tested DPU did not reach the target. SipHash-1-3-128 was the leading candidate, and FPGA or ASIC hashing is expected to be needed for some plans [[S-1311]].\n- **Passive optics (Amodo).** Amodo computes a 1.45 dB link margin for a representative 53 GBaud link; a 95/5 split costs about 0.25 dB on the live leg and about 13 dB on the monitor leg [[S-1310]].",
    "category": "off-chip-devices",
    "secondary_categories": [
      "cryptographic-computational"
    ],
    "verifies": [
      {
        "claim": "C-0004",
        "role": "primary",
        "note": "Supplies the committed record of cluster I/O that recomputation checks against declared inference (S-0067, S-1300)."
      },
      {
        "claim": "C-0009",
        "role": "supporting",
        "note": "Aims to make covert exfiltration of results through tapped links infeasible (S-1300)."
      },
      {
        "claim": "C-0005",
        "role": "supporting",
        "note": "Replaying challenged records with the declared model checks which model produced outputs (S-1300, S-0067)."
      }
    ],
    "threat_model": "adversarial",
    "adversarial_evaluation": "analysis",
    "hardware_requirement": "retrofit-device",
    "prover_cooperation": "required",
    "confidentiality": "partial",
    "depends_on": [
      {
        "target": "M-0001",
        "note": "Challenged records are checked by recomputing them."
      },
      {
        "target": "M-0002",
        "note": "Bit-exact replay is the main proposed way to remove covert capacity in model outputs."
      },
      {
        "target": "M-0017",
        "note": "Taps and gateway devices must be physically protected and the facility monitored so all traffic passes through them."
      },
      {
        "target": "M-0022",
        "note": "Radio, power-line and thermal channels bypass the tapped links."
      }
    ],
    "readiness": {
      "assessment": true,
      "level": "R1",
      "rubric_version": "1.0",
      "rationale": "R1: the Secure Gateway Device and related designs are public, but no tapped prototype has run at production link rates or with an active warden.\n\n- **R1** met: the Secure Gateway Device paper specifies the architecture, its goal (no covert exfiltration of results through tapped wires), its assumptions (physical monitoring, prover-held plaintext) and covert-channel estimates [[S-1300]]. Feasibility and cost analyses cover north-south, storage and compute-fabric taps [[S-0031]]. The MIRI overview places taps in a full reference architecture [[S-0018]], and the AI 2040 plan relies on them [[S-0067]].\n- **R2** not met: Amodo reports a passive fibre tap on a 1 Gbps uplink, with all 800 test inferences tapped and verified during a flood of non-whitelisted traffic [[S-1312]]. That result is provider-reported on a blog, at link rates far below production frontend links, and Amodo says the passive tap must become active to close side channels [[S-1312]]. No code is linked. The most mature Implementation, SASH's [[I-0008|confidential network logger]], has public code, but it runs a toy model through an inline software proxy that computes no hashes [[S-1319]] [[S-1320]]. [[I-0011]] and [[I-0012]] are proposed architectures assessed R1. The Secure Gateway Device paper states that empirical validation and red-teaming are still required [[S-1300]].\n\nConfidence is low because the Amodo result (real tap hardware, a stated adversarial load) could reasonably be read as meeting R2 in one key respect.",
      "evidence": [
        "S-1300",
        "S-0031",
        "S-0018",
        "S-0067",
        "S-1312",
        "S-1319",
        "S-1320"
      ],
      "next_level_gaps": [
        "An end-to-end tapped prototype with public code, or with results described in enough detail for an independent team to repeat.",
        "Hashing and tapping demonstrated at production frontend link rates (400 Gbps class), including minimum-size frames.",
        "A built active warden or Secure Gateway Device, with measured residual covert bandwidth.",
        "Red-teaming of tap bypass, covert channels and physical security."
      ],
      "confidence": "low",
      "assessed_by": [
        "ai-draft"
      ],
      "assessed_on": "2026-09-23",
      "status": "current",
      "dispute": null
    },
    "flaws": [
      {
        "assessment": true,
        "title": "Output nondeterminism leaves covert capacity",
        "kind": "theoretical-argument",
        "severity": "significant",
        "status": "open",
        "description": "Hashing cannot remove information hidden in the outputs themselves. The Secure Gateway Device paper estimates that about 0.1 bit per token remains even with seed-synchronized replay checks. For a 200k-GPU inference cluster at full load (2,000 tokens per GPU per second), that is about 40 Mbit/s of covert egress, enough to move a 1 TB model in under three days. The paper names this the core remaining challenge and points to deterministic replay or active scrubbing of hardware-induced entropy [[S-1300]]. An independent study found that an adversary who chooses the prompts roughly doubles the bits leaked per token under Gumbel-based inference verification [[S-1507]]; see [[M-0024]].",
        "sources": [
          "S-1300",
          "S-1507"
        ],
        "response": null
      },
      {
        "assessment": true,
        "title": "Some links cannot be passively tapped",
        "kind": "open-question",
        "severity": "significant",
        "status": "open",
        "description": "Cankaya notes that copper-connected scale-up domains (for example NVL72 racks and TPU v7 cubes) are much harder to tap than fibre, and that optical budgets make passive taps impractical on 400GBASE-SR8 multimode links [[S-0031]]. Amodo found no taps advertised for 53 GBaud links as of May 2026 [[S-1310]].",
        "sources": [
          "S-0031",
          "S-1310"
        ],
        "response": null
      },
      {
        "assessment": true,
        "title": "Encrypted fabrics hide plaintext from both parties",
        "kind": "open-question",
        "severity": "significant",
        "status": "open",
        "description": "Cankaya notes that with TEE-protected sessions, neither the operator nor the manufacturer can recover session keys after the session, so tapped traffic could not be opened for recomputation. For other encrypted fabrics, the operator can retain keys [[S-0031]].",
        "sources": [
          "S-0031"
        ],
        "response": null
      },
      {
        "assessment": true,
        "title": "Residual side channels in simple passive setups",
        "kind": "theoretical-argument",
        "severity": "significant",
        "status": "open",
        "description": "Amodo's analysis of its own tapped prototype lists unvalidated header fields, timing of permitted traffic and variation in response formatting as residual channels, and concludes that the passive tap must be replaced by an active one [[S-1312]].",
        "sources": [
          "S-1312"
        ],
        "response": null
      },
      {
        "assessment": true,
        "title": "Completeness rests on physical monitoring left out of scope",
        "kind": "open-question",
        "severity": "significant",
        "status": "open",
        "description": "The Secure Gateway Device paper assumes the facility is physically monitored, and states that the whole architecture depends on the device being the only communication channel. It names radio emanation, power-line signalling and thermal channels as covert channels beyond that scope [[S-1300]].",
        "sources": [
          "S-1300"
        ],
        "response": null
      },
      {
        "assessment": true,
        "title": "Verifier dictionary attacks on hashes",
        "kind": "theoretical-argument",
        "severity": "minor",
        "status": "mitigated",
        "description": "Hashes of very short outputs could be brute-forced by the verifier. The paper recommends hashing at least 5 tokens together, or at least 10 if the attacker filters for likely tokens [[S-1300]].",
        "sources": [
          "S-1300"
        ],
        "response": null
      }
    ],
    "blockers": [
      {
        "text": "No tap or hashing hardware has been shown at production frontend link rates; on tested CPUs, no algorithm kept up with minimum-size frames.",
        "theme": "performance-compatibility",
        "blocked_by": null,
        "sources": [
          "S-1311",
          "S-1310"
        ]
      },
      {
        "text": "Nondeterministic inference leaves covert capacity in outputs that hashing cannot remove.",
        "theme": "evidence-binding",
        "blocked_by": "M-0002",
        "sources": [
          "S-1300"
        ]
      },
      {
        "text": "Taps and gateway devices need tamper-evident housing and physical monitoring so that traffic cannot bypass them.",
        "theme": "hardware-trust",
        "blocked_by": "M-0017",
        "sources": [
          "S-1300",
          "S-0018"
        ]
      },
      {
        "text": "Radio, power-line and thermal channels are not addressed by network-level designs.",
        "theme": "coverage-hidden-compute",
        "blocked_by": "M-0022",
        "sources": [
          "S-1300"
        ]
      },
      {
        "text": "Red-teaming by specialists is called for but has not been reported.",
        "theme": "adversarial-validation",
        "blocked_by": null,
        "sources": [
          "S-1300"
        ]
      }
    ],
    "challenge_themes": [
      "evidence-binding",
      "coverage-hidden-compute",
      "performance-compatibility",
      "hardware-trust",
      "privacy-leakage",
      "adversarial-validation"
    ],
    "organizations": [
      "O-0101",
      "O-0160",
      "O-0201",
      "O-0202",
      "O-0209"
    ],
    "people": [],
    "sources": [
      {
        "source": "S-1300",
        "supports": "Secure Gateway Device architecture, goal, assumptions, scope, covert-channel estimates, storage, dictionary attacks, need for validation",
        "locator": "abstract; §1; §3; §4.1–4.2; §5.1–5.3; §6; appendices A–C"
      },
      {
        "source": "S-0031",
        "supports": "tap definition; placement options and cost fractions; copper, multimode and encryption limits",
        "locator": "sections on north-south, storage and compute-fabric taps; open problems"
      },
      {
        "source": "S-0018",
        "supports": "capture-everything principle; hashing over packet groups; failure conditions; perimeter size; commercial precedents; physical monitoring",
        "locator": "§2b; §3.1–3.2; §5.1.1"
      },
      {
        "source": "S-0067",
        "supports": "passive frontend taps feeding a recomputation server",
        "locator": "inference-only retrofitting proposal"
      },
      {
        "source": "S-1309",
        "supports": "first passive optical tap test at about 10 Gbps",
        "locator": "whole note"
      },
      {
        "source": "S-1310",
        "supports": "COTS tap availability by baud rate; optical budget; possible need for a new ASIC",
        "locator": "BLUF; passive and active tap sections"
      },
      {
        "source": "S-1311",
        "supports": "line-rate hashing benchmarks on CPU and DPU",
        "locator": "results and conclusions"
      },
      {
        "source": "S-1312",
        "supports": "tapped 1 Gbps prototype, whitelist, flood test result, residual side channels, need for active tap",
        "locator": "setup, results and side-channel sections"
      },
      {
        "source": "S-1319",
        "supports": "public prototype code of a network-logger demo: inline proxy, no hashing, 270M model",
        "locator": "README; components/"
      },
      {
        "source": "S-1320",
        "supports": "confidential network logger prototype and planned FPGA certificates",
        "locator": "whole post"
      },
      {
        "source": "S-1507",
        "supports": "prompt-controlled attack roughly doubling per-token leakage under Gumbel-based inference verification",
        "locator": "abstract"
      }
    ],
    "concepts": [
      "K-0014",
      "K-0024",
      "K-0009",
      "K-0020",
      "K-0013",
      "K-0022",
      "K-0008",
      "K-0019",
      "K-0001",
      "K-0002"
    ],
    "complements": [
      "M-0003",
      "M-0014",
      "M-0015",
      "M-0016",
      "M-0024"
    ],
    "alternatives": [
      "M-0008"
    ],
    "type": "mechanism",
    "implementations": [
      {
        "id": "I-0011",
        "title": "AI 2040 inference-only verification stack",
        "url": "https://trustbutveri.fyi/implementations/ai-2040-inference-only-verification-plan/"
      },
      {
        "id": "I-0012",
        "title": "Low-trust AI compute verification system overview",
        "url": "https://trustbutveri.fyi/implementations/low-trust-compute-verification-system-overview/"
      },
      {
        "id": "I-0008",
        "title": "SASH confidential network logger",
        "url": "https://trustbutveri.fyi/implementations/sash-confidential-network-logger/"
      }
    ],
    "url": "https://trustbutveri.fyi/mechanisms/network-taps-and-certifiers/",
    "source_file": "content/mechanisms/network-taps-and-certifiers.md",
    "flags_all": [
      "ai-drafted"
    ],
    "body_markdown": "## How it works\n\nA network tap is a device that \"mirror[s] network traffic without disrupting normal operation\" [[S-0031]]. Verification proposals use taps to build a record of what crossed a link, which the verifier can check later [[S-0031]] [[S-0018]]. The MIRI system overview states the principle as \"capture everything, challenge and audit random samples after\" [[S-0018]].\n\nIn the most detailed designs, the verifier never receives plaintext [[S-0018]] [[S-1300]]. 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 [[K-0001|prover]]) keeps the plaintext [[S-0018]] [[S-1300]]. 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 [[S-1300]]. A missing or mismatching preimage is a failure; a replay that does not reproduce points to false metadata or a technical fault [[S-0018]].\n\nThe AI 2040 plan proposes a simpler variant: passive taps on the frontend network copy all input and output traffic to a recomputation server ([[M-0001]], [[M-0003]]) [[S-0067]].\n\nTaps can sit at three levels [[S-0031]]:\n\n- **North-south (frontend) links** to the outside world, at an estimated material cost under 0.01% of the monitored data centre [[S-0031]].\n- **The storage fabric**, which carries model loads, dataset reads and checkpoint saves, at an estimated 0.3–0.5% of data-centre cost [[S-0031]].\n- **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 the note proposes sampling, for example 0.01% of traffic, about 20 Gb/s, through an optical circuit switch [[S-0031]].\n\nFor 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 [[S-0018]].\n\nA key aim of the \"Secure Gateway Device\" design is that no processor has to be trusted by both sides [[S-1300]]. 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 [[S-1300]]. 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 [[S-1300]].\n\nSASH'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\" [[S-1320]]; see [[I-0008]].\n\n## What it establishes\nThe Secure Gateway Device paper aims to make it \"infeasible to covertly exfiltrate the results of undisclosed workloads in the cluster through the tapped wires\" [[S-1300]]. Combined with replay, it would show that recorded outputs match declared workloads [[S-1300]] [[S-0067]]; see [[C-0004]] and [[C-0009]].\n\nIt does not establish:\n\n- **Device state.** Taps capture flows, not device state; the MIRI overview treats memory probes as complementary [[S-0018]].\n- **Absence of covert compute.** A north-south tap does not directly prevent covert workloads, only the exfiltration of their results [[S-1300]]. 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 [[S-1300]].\n- **Permissibility or compliance.** The paper does not decide which workloads should be allowed, or whether declared workloads comply [[S-1300]].\n\n## Threat model\n- 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 [[S-1300]].\n- The facility is physically monitored, so that all traffic passes through the gateway [[S-1300]].\n- The operator stores all hashed data for the agreement's duration [[S-1300]].\n- Replay needs reproducible inference ([[M-0002]]) [[S-0018]] [[S-1300]].\n- The MIRI overview models a covert adversary, deterred when the likelihood of detection times the cost of being caught exceeds the expected gain [[S-0018]].\n\n## Evidence\n- **Designs and analysis.** The Secure Gateway Device paper, Cankaya's feasibility note and the MIRI overview are design studies [[S-1300]] [[S-0031]] [[S-0018]]. The paper states that empirical validation is still required and calls for red-teaming by specialists [[S-1300]].\n- **Commercial precedent.** Taps are used for stock-exchange monitoring, packet capture, defence networks and lawful intercept [[S-0018]]. The MIRI overview says AI use needs changes for a nation-state covert adversary [[S-0018]].\n- **Amodo's first tap test (March 2026).** A passive multimode splitter on a link of about 10 Gbps copied both directions of traffic to a monitoring machine [[S-1309]].\n- **Amodo's tap survey (May 2026).** Commodity taps exist for 26 GBaud links, but none are advertised for 53 GBaud [[S-1310]].\n- **Amodo's hashing benchmarks (July 2026).** On an AMD EPYC server CPU, no tested hash algorithm reached line rate with 64-byte frames, and the tested DPU fell short of the 400 Gbps target [[S-1311]].\n- **Amodo's tapped prototype (September 2026).** A passive fibre tap on the 1 Gbps uplink of its inference-verification prototype fed a frame processor, which rebuilt inference requests and checked all other traffic against a whitelist [[S-1312]]. Amodo reports that all 800 test inferences were tapped and verified during a flood of about 1 Gbps of non-whitelisted traffic [[S-1312]].\n- **SASH logger.** SASH's public prototype passes every request through an inline software logger and re-runs it on a 270-million-parameter model; it computes no hashes of the traffic [[S-1319]]. See [[I-0008]].\n\n## Limitations\n- **Output steganography.** The paper estimates about 40 Mbit/s of covert egress from output nondeterminism for a 200k-GPU cluster, even with replay checks [[S-1300]]. An attacker who chooses the prompts roughly doubles per-token leakage under Gumbel-based verification [[S-1507]]; see [[M-0002]] and [[M-0024]].\n- **Line rate.** On tested CPUs, no hash algorithm kept up with minimum-size frames, and the tested DPU was insufficient [[S-1311]].\n- **Optics and copper.** Passive taps are impractical on 400GBASE-SR8 multimode links, and copper-connected racks are much harder to tap [[S-0031]]. For 53 and 106 GBaud links, Amodo says a new ASIC may be needed [[S-1310]].\n- **Encryption.** TEE-protected fabrics would hide plaintext from both parties [[S-0031]].\n- **Passive-tap side channels.** Amodo concludes that its passive tap must become active [[S-1312]].\n- **Bypass.** Physical monitoring, and radio, power-line and thermal channels, are outside the network design [[S-1300]]; see [[M-0017]] and [[M-0022]].",
    "body_text": "How it works A network tap is a device that \"mirror[s] network traffic without disrupting normal operation\" [S-0031]. Verification proposals use taps to build a record of what crossed a link, which the verifier can check later [S-0031] [S-0018]. The MIRI system overview states the principle as \"capture everything, challenge and audit random samples after\" [S-0018]. In the most detailed designs, the verifier never receives plaintext [S-0018] [S-1300]. 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 [S-0018] [S-1300]. 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 [S-1300]. A missing or mismatching preimage is a failure; a replay that does not reproduce points to false metadata or a technical fault [S-0018]. 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, Reproducible computation packets) [S-0067]. Taps can sit at three levels [S-0031]: - North-south (frontend) links to the outside world, at an estimated material cost under 0.01% of the monitored data centre [S-0031]. - The storage fabric, which carries model loads, dataset reads and checkpoint saves, at an estimated 0.3–0.5% of data-centre cost [S-0031]. - 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 the note proposes sampling, for example 0.01% of traffic, about 20 Gb/s, through an optical circuit switch [S-0031]. 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 [S-0018]. A key aim of the \"Secure Gateway Device\" design is that no processor has to be trusted by both sides [S-1300]. 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 [S-1300]. 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 [S-1300]. 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\" [S-1320]; 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\" [S-1300]. Combined with replay, it would show that recorded outputs match declared workloads [S-1300] [S-0067]; see This compute runs inference, not training and Model weights or data have not left the facility. It does not establish: - Device state. Taps capture flows, not device state; the MIRI overview treats memory probes as complementary [S-0018]. - Absence of covert compute. A north-south tap does not directly prevent covert workloads, only the exfiltration of their results [S-1300]. 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 [S-1300]. - Permissibility or compliance. The paper does not decide which workloads should be allowed, or whether declared workloads comply [S-1300]. 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 [S-1300]. - The facility is physically monitored, so that all traffic passes through the gateway [S-1300]. - The operator stores all hashed data for the agreement's duration [S-1300]. - Replay needs reproducible inference (Deterministic and bit-exact inference) [S-0018] [S-1300]. - The MIRI overview models a covert adversary, deterred when the likelihood of detection times the cost of being caught exceeds the expected gain [S-0018]. Evidence - Designs and analysis. The Secure Gateway Device paper, Cankaya's feasibility note and the MIRI overview are design studies [S-1300] [S-0031] [S-0018]. The paper states that empirical validation is still required and calls for red-teaming by specialists [S-1300]. - Commercial precedent. Taps are used for stock-exchange monitoring, packet capture, defence networks and lawful intercept [S-0018]. The MIRI overview says AI use needs changes for a nation-state covert adversary [S-0018]. - Amodo's first tap test (March 2026). A passive multimode splitter on a link of about 10 Gbps copied both directions of traffic to a monitoring machine [S-1309]. - Amodo's tap survey (May 2026). Commodity taps exist for 26 GBaud links, but none are advertised for 53 GBaud [S-1310]. - Amodo's hashing benchmarks (July 2026). On an AMD EPYC server CPU, no tested hash algorithm reached line rate with 64-byte frames, and the tested DPU fell short of the 400 Gbps target [S-1311]. - Amodo's tapped prototype (September 2026). A passive fibre tap on the 1 Gbps uplink of its inference-verification prototype fed a frame processor, which rebuilt inference requests and checked all other traffic against a whitelist [S-1312]. Amodo reports that all 800 test inferences were tapped and verified during a flood of about 1 Gbps of non-whitelisted traffic [S-1312]. - SASH logger. SASH's public prototype passes every request through an inline software logger and re-runs it on a 270-million-parameter model; it computes no hashes of the traffic [S-1319]. See SASH confidential network logger. Limitations - Output steganography. The paper estimates about 40 Mbit/s of covert egress from output nondeterminism for a 200k-GPU cluster, even with replay checks [S-1300]. An attacker who chooses the prompts roughly doubles per-token leakage under Gumbel-based verification [S-1507]; see Deterministic and bit-exact inference and Bounding unexplained information in outputs. - Line rate. On tested CPUs, no hash algorithm kept up with minimum-size frames, and the tested DPU was insufficient [S-1311]. - Optics and copper. Passive taps are impractical on 400GBASE-SR8 multimode links, and copper-connected racks are much harder to tap [S-0031]. For 53 and 106 GBaud links, Amodo says a new ASIC may be needed [S-1310]. - Encryption. TEE-protected fabrics would hide plaintext from both parties [S-0031]. - Passive-tap side channels. Amodo concludes that its passive tap must become active [S-1312]. - Bypass. Physical monitoring, and radio, power-line and thermal channels, are outside the network design [S-1300]; see Tamper evidence for verifier devices and Side-channel suppression for isolated facilities.",
    "referenced_by": [
      {
        "id": "M-0014",
        "title": "Bandwidth limits and compartmentalization",
        "url": "https://trustbutveri.fyi/mechanisms/bandwidth-limits-and-compartmentalization/"
      },
      {
        "id": "M-0024",
        "title": "Bounding unexplained information in outputs",
        "url": "https://trustbutveri.fyi/mechanisms/bounding-unexplained-information/"
      },
      {
        "id": "M-0002",
        "title": "Deterministic and bit-exact inference",
        "url": "https://trustbutveri.fyi/mechanisms/deterministic-inference/"
      },
      {
        "id": "M-0009",
        "title": "Hardware-enabled guarantees (flexHEG) and guarantee processors",
        "url": "https://trustbutveri.fyi/mechanisms/flexheg-guarantee-processors/"
      },
      {
        "id": "M-0015",
        "title": "Memory wiping and proofs of secure erasure",
        "url": "https://trustbutveri.fyi/mechanisms/memory-wiping-and-secure-erasure/"
      },
      {
        "id": "M-0003",
        "title": "Reproducible computation packets",
        "url": "https://trustbutveri.fyi/mechanisms/reproducible-computation-packets/"
      },
      {
        "id": "M-0001",
        "title": "Sampled inference recomputation",
        "url": "https://trustbutveri.fyi/mechanisms/sampled-inference-recomputation/"
      },
      {
        "id": "M-0022",
        "title": "Side-channel suppression for isolated facilities",
        "url": "https://trustbutveri.fyi/mechanisms/side-channel-suppression/"
      },
      {
        "id": "M-0017",
        "title": "Tamper evidence for verifier devices",
        "url": "https://trustbutveri.fyi/mechanisms/tamper-evidence-for-verifier-devices/"
      },
      {
        "id": "M-0016",
        "title": "Timed challenge-response and memory-occupation challenges",
        "url": "https://trustbutveri.fyi/mechanisms/timed-challenge-response/"
      },
      {
        "id": "M-0021",
        "title": "Workload classification from telemetry and side channels",
        "url": "https://trustbutveri.fyi/mechanisms/workload-classification-from-telemetry/"
      },
      {
        "id": "M-0005",
        "title": "Zero-knowledge proofs of training constraints",
        "url": "https://trustbutveri.fyi/mechanisms/zk-proofs-of-training-constraints/"
      },
      {
        "id": "I-0011",
        "title": "AI 2040 inference-only verification stack",
        "url": "https://trustbutveri.fyi/implementations/ai-2040-inference-only-verification-plan/"
      },
      {
        "id": "I-0012",
        "title": "Low-trust AI compute verification system overview",
        "url": "https://trustbutveri.fyi/implementations/low-trust-compute-verification-system-overview/"
      },
      {
        "id": "I-0008",
        "title": "SASH confidential network logger",
        "url": "https://trustbutveri.fyi/implementations/sash-confidential-network-logger/"
      },
      {
        "id": "C-0004",
        "title": "This compute runs inference, not training",
        "url": "https://trustbutveri.fyi/claims/inference-not-training/"
      },
      {
        "id": "C-0009",
        "title": "Model weights or data have not left the facility",
        "url": "https://trustbutveri.fyi/claims/weights-have-not-left/"
      },
      {
        "id": "K-0024",
        "title": "Cryptographic commitment",
        "url": "https://trustbutveri.fyi/concepts/cryptographic-commitment/"
      },
      {
        "id": "K-0019",
        "title": "Evidence binding",
        "url": "https://trustbutveri.fyi/concepts/evidence-binding/"
      },
      {
        "id": "K-0014",
        "title": "Network tap",
        "url": "https://trustbutveri.fyi/concepts/network-tap/"
      },
      {
        "id": "O-0201",
        "title": "AI Futures Project",
        "url": "https://trustbutveri.fyi/organizations/ai-futures-project/"
      },
      {
        "id": "O-0101",
        "title": "Amodo Design",
        "url": "https://trustbutveri.fyi/organizations/amodo-design/"
      },
      {
        "id": "O-0202",
        "title": "Machine Intelligence Research Institute",
        "url": "https://trustbutveri.fyi/organizations/machine-intelligence-research-institute/"
      },
      {
        "id": "O-0209",
        "title": "Hardware AI Governance Lab",
        "url": "https://trustbutveri.fyi/organizations/oxford-hardware-ai-governance-lab/"
      },
      {
        "id": "O-0160",
        "title": "Singapore AI Safety Hub (SASH)",
        "url": "https://trustbutveri.fyi/organizations/singapore-ai-safety-hub/"
      },
      {
        "id": "O-0203",
        "title": "Verifiable Compute Foundation",
        "url": "https://trustbutveri.fyi/organizations/verifiable-compute-foundation/"
      }
    ]
  }
}