2.1.6 Where Should Trust Live?

Allow 20 minutes for the three required reading cards, 35 minutes for the lesson, and 30 minutes for the exercise and answer review. Each card assigns an excerpt, not a complete paper. No code, hardware access, installation, or cryptographic calculations are required. Other inline links are references, not extra assignments.

Move the Mechanism, Move the Trust

In 2.1.5, we followed permission from an authority to a device and back through review and recovery. Now ask where the machinery that measures, interprets, and restricts activity should be placed.

A monitor built into an accelerator may see internal activity that an external observer cannot. A separate monitor may reduce reliance on that accelerator’s manufacturer, but only if its evidence does not simply repeat what the accelerator reports. A physical sensor can observe a different phenomenon, yet may reveal little about the purpose of the computation. Combining them can help—or leave several devices repeating the same mistake.

Keep the pause claim from 2.1.1: no covered, unlicensed training run exceeded the agreed threshold. We are comparing architectures that might support parts of that claim, not assuming any architecture already establishes it. This lesson does not select an entire international regime.

Locate Three Functions, Not One Box

Every proposal should distinguish:

1. Collection: where the observation originates, such as a counter, intercepted data, or a current sensor.
2. Appraisal: where observations are interpreted against a rule, reference value, or model of expected behavior.
3. Control: where an instruction can actually constrain computation, if the design includes enforcement.

These functions can occupy different components. A power sensor is not necessarily a workload classifier. A classifier is not necessarily a switch. An external processor that checks signatures may provide independent appraisal of authenticity without independently measuring the underlying activity.

A measurement boundary is the set of devices, pathways, and intervals the observation covers. Draw that boundary before discussing confidence. A network observer at the edge of a rack does not automatically see traffic inside it. A meter on one electrical feed does not measure an unmetered feed elsewhere.

Likewise, distinguish physical location from dependence. An off-chip appliance can remain dependent on on-chip firmware for every input. An analog sensor normally produces records that digital software stores and analyzes. “Analog” describes the originating measurement, not an absence of software or cryptography.

Four Architectural Choices

The following is a course-authored comparison of representative designs, not a universal ranking or vendor specification. A specific implementation may change any entry.

The attraction of moving monitoring outside the accelerator is not that external hardware is inherently trustworthy. It is the opportunity to choose a different design, supplier, maintenance process, and measurement path. Whether that opportunity is realized must be demonstrated.

Baker and colleagues distinguish on-chip verification from external digital loggers and analog sensors, and discuss separate protected analysis. Their proposal also treats verifier equipment as a possible source of espionage or sabotage against the party being monitored. That two-sided problem is central here.

Sort the Mechanisms

The table above sorts clean examples. A procurement document does not arrive sorted, and the first question to ask of any row in one is what it observes and where that observation starts.

Digital Access Is Not Complete Visibility

Suppose a tap records every message passing through a particular network port. That establishes coverage of that port, not of all computation on the attached devices. Some work may occur without crossing it. Even observed traffic may be encrypted, and readable messages do not automatically reveal which high-level training procedure produced them.

The architecture therefore needs two arguments: why relevant activity produces an observable trace at that boundary, and why the trace supports the particular claim. Neither follows just from the word “tap.” If decryption or workload declarations are required, add their keys and providers to the dependency map.

There is also a difference between observing a copy and sitting on a required path. A passive observer reads traffic; an interlock is a component placed on a path whose passage it can mediate. A design may aim to make work impossible without passing through that component. That is a stronger requirement than merely placing a recorder nearby.

Petrie and Aarne explore an interlock on an accelerator’s data path, supported by a guarantee processor and physical protection. They explicitly discuss the performance burden of this placement and several possible integration points. Their interlock is not necessarily off-chip: placement is a design choice. This is an architecture proposal, not a demonstration that arbitrary existing GPUs can be comprehensively monitored by adding a network box.

Physical Measurement Changes the Question

In 2.1.4, we distinguished resource consumption from workload purpose. Here the distinction becomes architectural. A separately installed electrical meter could remain informative when accelerator firmware lies. But it measures electrical consumption at its boundary, not “unlicensed training.”

The inference still needs a defensible relationship between declared work and observed consumption, with uncertainty for other loads and operating conditions. A sensor may be independent of the vendor’s reporting path while its interpretation is not: for example, both analyses may depend on the same vendor-supplied efficiency model.

Ask who calibrates the sensor, verifies its placement, handles replacement, and checks that all relevant feeds remain covered. A broken seal can indicate a need to investigate. An intact-looking seal is not a logical proof that no intervention occurred. Tamper resistance makes interference harder; tamper evidence makes some interference detectable. Neither term means invulnerability.

Physical signals may also disclose sensitive operational patterns. “We do not read model weights” is narrower than “we reveal nothing sensitive.” Collection resolution, retention, access, and release rules still matter.

We do not repeat the compute-accounting derivation here. The architectural question is which assumptions the physical observation removes, and which assumptions its interpretation introduces.

Historical Case — Different Certificate Chains, Shared Control

In September 2011, Mozilla removed trust in the DigiNotar certificate authority after fraudulent certificate issuance. Its account described an uncertain breach scope and failures of notification. Certificates issued through a different DigiNotar-controlled intermediate for the Dutch government were initially exempted; Mozilla removed that exemption after the Dutch government’s assessment changed.

A certificate authority vouches for the relationship between an identity and a public key. Here, the architecture lesson is that different certificate chains did not settle whether the underlying processes were independently secure. It is not a claim that every certificate was fraudulent, or that cryptography itself failed.

For our purposes, the incident motivates a question: if different monitoring components share an issuing organization or administrative system, what could one compromise invalidate? Count the dependencies, not the certificates.

A Hybrid Is Not Automatically Redundant

Complementary mechanisms answer different questions. Redundant mechanisms provide overlapping assurance about the same question. Either can be useful. Neither is established by the number of boxes.

Consider three supposed checks: a device report, a second report from an external appliance, and an auditor’s dashboard. If the appliance imports the first report and the dashboard summarizes it, there is one originating measurement with several consumers. Independent signatures could protect each handoff while preserving an error in the original evidence.

Other dependencies are less visible:

• Two collectors accept updates from the same compromised signing service.
• Different sensors use the same incorrect device-to-job mapping.
• Separate records all omit activity during the same maintenance interval.
• A second laboratory repeats an analysis using the same flawed reference model.

A common-mode failure is one cause undermining several protections together. Independence is relative to a cause: separate power measurement may resist forged GPU telemetry, yet both paths may still depend on one registry to identify the covered fleet. Do not multiply hypothetical error rates as if independence were established.

To test a hybrid, remove one dependency in thought. If the vendor’s firmware reports false values, what evidence remains? If the common update authority is compromised, what survives? If the facility supplies the wrong inventory, which mechanism could notice? State the surviving claim, not just the surviving device.

The Monitor Is Inside Someone Else’s Security Boundary

The verifier wants accurate, complete observations. The operator wants protection of models, data, and legitimate service. The host state may also reject equipment that a foreign actor could use for surveillance or disruption. A design trusted by one of these actors can be unacceptable to another.

For a candidate architecture, name who supplies the collector, controls its software updates, has physical access, reads raw records, approves outputs, and can restore service. Manufacturer involvement might provide necessary interface knowledge while creating dependence on a party one state distrusts. Verifier-supplied equipment might strengthen confidence in measurement while alarming the operator about hidden capabilities.

Possible accommodations include reviewed designs, controlled installation, jointly approved updates, restricted communications, bounded retention, and supervised maintenance. These are design requirements to test, not assurances supplied by their labels. Open source permits examination of a design; it does not establish that the installed device matches it or that no flaw escaped review.

Confidentiality controls need their own coverage argument. Restricting ordinary network output does not automatically cover maintenance interfaces, removable storage, or personnel. Nor should an operator’s confidentiality veto silently become a power to replace inconvenient measurements. Specify what happens when the parties disagree about a disclosure.

The same applies to enforcement. A passive meter cannot implement the suspension procedure from 2.1.5 by itself. Adding a power-control device changes the architecture’s availability risks and authority structure. Do not smuggle a new control power into a diagram labeled “verification.”

Exercise — Three Green Reports

Hypothetical procurement review. Two states are considering a six-month monitoring pilot at one registered facility. The operator will not release model weights or raw workload contents outside the facility. The inspectorate wants evidence about aggregate counted computation and possible undeclared use. Both states worry about the other’s influence over suppliers. This pilot cannot establish that no other facilities exist.

A supplier describes its proposal as “three independent hardware verification layers.” Its specification says:

All three reports are green. No compromise has been established.

The supplier concludes: “Agreement among three independently signed reports proves compliance, even if one vendor component is compromised.”

Questions

Carry Forward

For any architecture, finish this sentence:

“If [one named component or authority] fails or becomes adversarial, [specified evidence] still supports [bounded claim], provided [remaining assumptions] hold.”

If the surviving claim is much narrower than the headline promise, record that gap. If nothing survives, record the dependency honestly. The optional 2.1.7 examines independent checks of declared training.