Physical Security for AI Nodes: Tamper-Evident Mechanisms on the E31 Series

Most conversations about AI security start and end at the network boundary: who can reach the model over the wire, what the API surface exposes, how inference requests are authenticated. That framing quietly assumes the hardware itself is out of scope, sitting in a data center someone else controls, behind someone else's badge readers. For a sealed appliance running on-premises, in a facility the vendor does not operate, that assumption does not hold. The node is not abstracted away behind a cloud provider's physical security program. It is a box, on a rack, in a room, and the box itself has to answer for its own security posture. That is the problem tamper-evident design solves, and it is worth being precise about what the term does and does not claim.

It does not claim the enclosure cannot be opened. With enough time, tooling, and disregard for warranty terms, almost any enclosure can be opened. What it claims is narrower and more useful: that opening it leaves a mark, and that the mark is detectable by someone other than the person who made it. Tamper-proof is a physics problem nobody has fully solved. Tamper-evident is an engineering problem with a real answer, and it is the one that matters for AI hardware that sits outside the vendor's own facilities.

Why the node is a distinct attack surface

An AI appliance is not just a server. It typically holds three things an adversary would value differently than a generic compute box: model weights that may represent significant investment to train or fine-tune, retrieval indices and cached context built from an organization's own sensitive material, and cryptographic key material that governs what the device is willing to run and trust. A network attacker who compromises the appliance over the wire has to fight the software stack. Someone with physical access to the chassis can, in principle, skip that fight entirely by pulling a drive, probing a bus, swapping firmware, unless the hardware is built to make that kind of access self-reporting.

This is the case for treating physical security as a first-class part of an AI deployment's threat model rather than an assumption inherited from where the box happens to sit. A facility's badge system and camera coverage are real controls, but they are the customer's controls, not the appliance's, and they vary by site. What travels with the hardware itself What holds regardless of which loading dock, closet, or field location a given unit ends up in is what the enclosure and firmware are built to guarantee on their own.

The enclosure is the first layer, not the only one

At the physical layer, a tamper-evident enclosure combines a few unremarkable-sounding mechanisms into something that is hard to defeat quietly. Fasteners that deform or shear rather than back out cleanly. Seams and access panels covered by seals designed to fracture visibly under removal rather than lift and reseat. Conformal potting or shielding over board areas where probing would otherwise be easy: memory buses, debug headers, anything that gives an attacker a low-effort path to data or key material without going through the software stack at all. None of these mechanisms is exotic; the discipline is in applying all of them consistently, to a written enclosure specification, rather than treating physical security as an afterthought bolted onto a commodity chassis.

The honest caveat: physical seals raise the cost and skill floor of covert intrusion, and they make overt intrusion visible. They do not, by themselves, stop a sufficiently resourced and patient adversary from getting inside. That is why the enclosure is described here as the first layer. The property that actually matters, whether an intrusion is detected and whether the appliance responds correctly once it is, depends on what happens next, at the firmware and key-management layer, not on the case holding forever.

Detection has to survive the thing it's detecting

A tamper mechanism that can be silenced by the same access that triggers it is not a tamper mechanism, it is a suggestion. This is the design constraint that separates sealed hardware from a locked box: the detection state has to be independent of the component being tampered with, and it has to persist through a power cycle, because an attacker with physical access can always cut power.

In practice this means tamper state lives in circuitry with its own power domain, typically a small reserve supply dedicated to keeping a tamper-detect latch alive, so that disconnecting main power does not erase the fact that a seal was broken or a chassis switch was triggered. On next boot, firmware reads that latch before it does anything else. A tripped latch is not a warning logged alongside normal boot messages; it changes what the node is willing to do next, including whether it will unseal storage keys or bring model weights into memory at all.

What tamper evidence protects, and what it doesn't

This is where the enclosure work and the cryptographic work meet, and where loose language causes the most confusion. Sealing the case does not encrypt anything, and detecting intrusion does not by itself stop it. What the seal buys is assurance that if the case was opened, the appliance knows — and what the appliance does with that knowledge is a firmware and key-management decision, not a physical one.

Storage on an E31 node is encrypted at rest, with keys that are not simply sitting in flash next to the data they protect. The design goal is that a drive pulled from a tampered unit is not a data breach, it is a chunk of ciphertext — and that the keys needed to make sense of it are either held in protected key-management hardware that itself resists extraction, or bound to a chain of trust the appliance validates at boot and refuses to complete if that chain looks wrong. A tripped tamper latch is one of the signals that chain checks against: firmware can be configured to treat detected intrusion as a reason to halt, to refuse to unseal storage keys, or to require an out-of-band re-provisioning step before the node will run again. The exact posture is a policy choice tuned to the deployment; the property that has to hold regardless is that physical possession of the hardware is not, by itself, sufficient to read the data or exfiltrate the weights it holds.

This is not a claim that any appliance is immune to all forms of extraction under unlimited resources and time. No vendor can honestly make that claim about hardware, and treating key-extraction research as a solved problem is how security stories become false ones. It is a claim that the ordinary threat, a stolen unit, an insider who walks off with hardware, a device that goes missing in transit or storage, degrades gracefully into "we lost a sealed box" rather than "we lost the model and the data behind it."

Why this has to be verifiable, not just true

A review board cannot inspect a node's internals directly, and shouldn't have to. What it can inspect is the record: does the appliance expose tamper state as a checkable status rather than a black box, does the manufacturer document what the detection mechanisms actually cover and what they don't, and is the boot-time response to a tripped latch specified behavior rather than best-effort behavior that depends on which build happens to be running. Tamper evidence that only the vendor can see is not evidence a customer's compliance program can rely on.

This matters most for organizations whose deployment sites are not uniformly secured facilities: field locations, partner sites, or any environment where the operator does not fully control who has access to the room. The point of building tamper detection at the platform level, consistently, across every unit, as part of a signed and documented configuration, is that the reviewer's question stops being "do we trust this vendor's word" and becomes "does this unit's status match its provisioning record," which is a much shorter conversation, and one that holds up the same way regardless of where the hardware physically sits.

Where this matters across the lineup

This layer of the design earns its keep hardest on Czar, where the sandbox is built specifically to hold sensitive training data — material an organization is fine-tuning on precisely because it cannot leave the building — and where the threat model has to include the hardware itself walking out the door, not just network attackers. Forge, as a repo-aware coding assistant appliance, carries the same enclosure and firmware discipline, since source code and the models trained on it are exactly the kind of asset physical tamper detection is meant to protect. Chassis builds inherit the same underlying Substrate platform and the same tamper detection primitives, but the specific posture for a given Chassis unit, how aggressively it locks down on a tripped latch, what re-provisioning looks like, is set by the deal it was built for, not by a generic default, since each Chassis build ships into a different ISV's environment under different assumptions about who controls physical access.

None of this substitutes for the rest of a security architecture: network segmentation, access control, personnel policy still matter regardless of what the case is made of. What sealed, tamper-evident hardware contributes is narrower and more concrete: it converts "we believe no one touched this node" from an assumption inherited from the facility into something the appliance itself can attest to, on demand, every time someone asks.