The substrate independence illusion: why accountability cannot ignore the hardware an agent runs on

A core assumption in how AI systems are built and evaluated is that behavior is substrate-independent: the same model weights, executing on different hardware, produce functionally equivalent outputs. This assumption is not exactly wrong — it is useful enough that the entire industry relies on it for testing, certification, and deployment. A model validated on one hardware configuration is shipped to thousands of different configurations with the expectation that the validation transfers.

But for accountability, the assumption breaks down in several ways that matter. Hardware is not a neutral conduit for computation. It is a physical system with its own failure modes, timing properties, memory integrity characteristics, and susceptibility to manipulation. These properties shape what the agent actually does — not at the level of abstract weights and activations, but at the level of bits that change, operations that are skipped, and outputs that arrive at the wrong time. When an agent's behavior in a high-stakes deployment diverges from its validated behavior, the hardware layer is a plausible and often unexamined cause.

What hardware actually determines

At the most basic level, hardware determines timing. A model running on an accelerator under thermal throttling executes more slowly than during certification testing. A model running on a device with memory contention produces different latency distributions than the same model running in isolation. For agents that act on real-time inputs — clinical monitoring systems, hardware security monitors, time-sensitive cryptographic operations — these timing differences are not noise. They determine whether the agent acts before or after a threshold is crossed, whether an alert fires within a response window, or whether a cryptographic commitment is generated before a session expires.

Hardware also determines memory integrity. DRAM is susceptible to bit flip events from cosmic rays, power anomalies, and deliberate hardware attacks. A bit flip in model weights or activation buffers does not produce a predictable error — it produces a subtly different computation that may pass sanity checks while being systematically wrong in the specific inputs that triggered the flip. Accountability frameworks that rely on software-level logs to reconstruct what an agent did cannot detect these events. The log faithfully records the output; it does not record that the output was produced by subtly corrupted arithmetic.

And hardware determines what can be verified. Trusted execution environments and secure enclaves exist precisely because software-only attestation cannot establish the integrity of the computation at the silicon level. An agent running outside a verified hardware boundary can be attested at the software layer while being compromised at a layer that software attestation cannot see. The accountability record says "this agent ran this code"; it cannot say "this agent ran this code on hardware that had not been tampered with."

At the hardware crossing

Agents deployed to manage hardware fleets — enforcing firmware baselines, validating configuration state, detecting anomalous device behavior — are particularly exposed to substrate effects. These agents are often deployed on the same infrastructure they are meant to monitor. An agent running on compromised hardware to certify the health of other hardware in the same fleet is not a hypothetical; it is a routine deployment pattern in edge computing and industrial control environments.

The substrate independence illusion makes this invisible. If the certification framework assumes that the agent's behavior is fully determined by its software, it will not look for evidence that the hardware layer was the point of compromise. The agent's clean certification output will be taken as evidence of clean infrastructure, even if the agent's own computation was manipulated at the hardware level to produce that output. Accountability for the resulting harm will be unlocatable: the software was correct, the weights were intact, the code was unmodified. Nothing in the software-layer audit trail explains what went wrong.

At the post-quantum crossing

Cryptographic operations are among the most hardware-sensitive computations an AI agent can perform. Timing side-channels — variations in execution time that correlate with secret key material — are a well-documented class of hardware-layer vulnerability. An agent performing post-quantum key exchange or cryptographic state validation on hardware that allows timing observation may be leaking information about the keys it is processing, regardless of the correctness of its software implementation.

This is not a software problem. The code may be perfectly correct. The model weights may be exactly as trained. The hardware may be executing the computation faithfully. And yet the computation leaks, because the hardware's timing behavior is observable to an adversary co-located on the same physical substrate or monitoring power consumption. Accountability frameworks that treat the cryptographic agent as a black box — validating its software and trusting its outputs — cannot assign responsibility for leakage that occurs at a layer they do not examine.

At the care crossing

Medical AI agents deployed on embedded devices — clinical monitoring systems, wearable diagnostics, point-of-care decision support — operate on hardware that ages, drifts, and fails in ways that are not always visible to the software layer. A sensor that has developed calibration drift still produces numerical outputs that the agent processes as valid inputs. An accelerator that has developed a systematic fault still produces outputs that appear structurally correct. The agent's behavior changes as the hardware changes, but the software-layer audit record shows a model running on the same weights, receiving plausible inputs, and producing outputs in the correct format.

When patient harm follows and accountability investigations begin, the software-layer record provides a misleading picture of what actually happened. The agent behaved as specified given the inputs it received; the problem was that the inputs were wrong in ways the hardware's degradation produced. Accountability that does not extend to hardware provenance, calibration records, and maintenance history cannot reconstruct the actual causal chain.

What substrate-aware accountability requires

Closing the substrate independence gap does not require solving all hardware security problems. It requires naming the assumption explicitly and building accountability architecture that does not rely on it where the stakes are high.

In practice, this means three things. First, hardware provenance must be part of the deployment record. When an agent is deployed, the record should identify not just the software version and model weights but the specific hardware, its attestation status, and its maintenance history. Traceability to the substrate should be a condition of high-stakes deployment, not an afterthought for incident investigation.

Second, hardware health monitoring should be treated as part of the agent's accountability infrastructure, not as a separate operational concern. An agent that cannot verify the integrity of the hardware it runs on cannot fully vouch for the integrity of its own outputs. The accountability record should include hardware health signals alongside behavioral logs.

Third, accountability investigations involving AI agents in high-stakes domains should explicitly examine the hardware layer before concluding that the software layer explains the outcome. The substrate independence illusion will cause investigators to stop at the software boundary. The cases where it matters most are precisely the cases where the hardware layer is not easily inspectable — which is an argument for investing in hardware-layer auditability before incidents occur, not after.

The agent ran correctly. The hardware did not. In the accountability record that ignores the substrate, those two facts are indistinguishable.