Attesting a machine that moves

Attestation, reduced to one sentence: a computer proves — with evidence rooted in hardware rather than in its own report — which hardware, firmware, and software actually ran. Each boot stage measures the next before handing over control, and the accumulated measurements form a chain that a verifier can check against known-good values. Not "the machine says it's fine," but "the machine can demonstrate what it is."

The technique matured in datacenters, where it hardens an already-strong position: servers live in locked rooms with badge readers and camera coverage. Physical access is the exception. Attestation there is a second wall behind a first one.

A robot has no first wall.

The threat model has wheels

A machine that works for a living is handled. It is transported in trucks, parked overnight in yards, serviced by contractors, recovered after faults by whoever is closest. Its ports are reachable. Its enclosure is openable with ordinary tools and ordinary opportunity. Every assumption that makes a datacenter's physical security story work is false on a loading dock.

And the stakes are inverted, too. A compromised server leaks or lies — serious, but informational. A compromised robot is a machine with mass, speed, and reach doing something nobody authorized, near people. That is not a data breach with unusual packaging; it is a safety event. Integrity, for embodied systems, is a safety property, and it deserves the same architectural seriousness as an interlock.

This is why "it looks fine" — the operational integrity model of most deployed fleets today — is not a model at all. Visual inspection detects stickers and dents. It does not detect firmware.

What the proof has to cover

For attestation to carry safety weight on a mobile machine, it has to answer four questions, continuously and on demand:

• Which hardware? That this specific unit — not a substituted board, not a cloned identity — is the one provisioned into the fleet.
• Which firmware and image? That every stage from first boot to workload is exactly the signed artifact that was approved, with nothing inserted between stages.
• Which model? Behavior lives in weights now. A model update changes how the machine moves, so the running model's provenance — who trained it, who signed it, who approved it for this site — is part of the machine's integrity, not metadata beside it.
• Since when? A machine that was verified last month and handled yesterday is a machine whose proof has expired. Re-attestation has to be cheap enough to happen at operationally meaningful moments: on boot, on rejoin, after service, before sensitive tasks.

The consequence side matters as much as the evidence side: a machine that cannot produce proof must be treated as compromised — excluded from coordination, denied work, flagged for inspection — automatically, not after a meeting. An attestation result that doesn't gate anything is a dashboard, not a control.

Governance without visibility

There is a subtlety in doing this across sites. The operator of twenty facilities needs fleet-wide integrity evidence; the facilities need their operational data to stay inside their boundaries. These pull in opposite directions if the design conflates evidence with data.

They are separable. Attestation evidence — measurements, signatures, verdicts — says what a machine is running and discloses nothing about what the machine saw or did. A fleet plane can therefore verify every site's integrity while remaining blind to every site's operations: authority flows down as signed artifacts, evidence flows up as measurements, and video, telemetry, and throughput flow nowhere. For air-gapped sites, the same exchange rides signed bundles across the boundary instead of a connection.

That asymmetry — govern everything, see nothing — is the property E31 Network's fleet plane is being designed around. It is also, we suspect, the property that will eventually separate infrastructure that regulated operators can accept from infrastructure they cannot.