The Black Box Approach: Protecting Trade Secrets on Hardware the Client Owns

Every ISV that sells into a secure facility eventually runs into the same uncomfortable trade. The buyer wants the unit on their premises, under their power, inside their perimeter, with no dependency on a network path back to the vendor. The ISV wants exactly the opposite for its own asset: the model weights, the fine-tuning data, the inference pipeline, the years of accumulated tuning that make the product worth buying in the first place, kept out of reach of the party who now physically possesses the box it runs on.

Those two wants are not actually in conflict, but they get treated as if they are, because most people conflate two questions that have completely different answers. Who has physical custody of this hardware is a facilities and procurement question, and the answer is almost always the buyer. That is the entire point of an air-gapped deployment. Who can read, extract, or reverse the software running on it is a completely different question, with a completely different answer, and it does not have to track physical custody at all. A locked safe sitting in someone else's living room is still a locked safe. The interesting engineering is in making sure that stays true even when the person holding the safe has unlimited time, a workbench, and no one watching.

Custody is not the same thing as access

It helps to name the actual adversary here, because it is not a hypothetical hacker on the internet. The whole premise of an air-gapped appliance is that there is no internet path to worry about. The adversary in this scenario is the buyer's own facility: a curious systems administrator, a competitor who later acquires or partners with the buyer, a foreign intelligence service that gains access to the buyer's building through means that have nothing to do with the ISV. The unit sits inside a boundary the ISV does not control and cannot monitor in real time. Whatever protects the ISV's intellectual property has to survive an adversary with the box in hand, unlimited time, and no one from the vendor watching over their shoulder.

This is a fundamentally different threat model than protecting a SaaS backend, and treating it like the same problem is where a lot of well-intentioned engineering goes wrong. A cloud application protects its source and its weights by controlling the perimeter around the server: access control, network segmentation, physical security the vendor operates directly. None of that transfers to a box the vendor has shipped out the door. The perimeter the ISV used to control now belongs to someone else. What has to do the protecting instead is the box itself.

What "black box" actually has to mean

The phrase gets used loosely, so it is worth being precise about what a genuine black-box posture requires, layer by layer, because each layer defeats a different kind of attempt to look inside.

At the physical layer, the enclosure has to make opening it detectable, not merely difficult. This is the tamper-evident discipline underneath every Element 31 build: seals, sensors, and a chassis designed so that an intrusion attempt leaves a mark a review board (the ISV's own, or the buyer's) can verify later, even if the attempt itself was never observed in real time. The goal is not an unopenable box, which does not exist. The goal is a box where opening it without authorization is a self-reporting event.

At the storage layer, model weights, fine-tuned parameters, and proprietary code have to be encrypted at rest in a way that ties decryption to the sealed hardware's own attestation state, not to a password or key that could be extracted from the unit alongside the data it protects. A drive pulled from the chassis and read on a bench elsewhere should yield nothing usable. This is the difference between "the software is on the disk" and "the software is only ever intelligible inside this specific, sealed piece of hardware in a verified state."

At the boot and runtime layer, the system has to verify its own integrity before it will run anything: a measured boot chain that confirms firmware and software haven't been altered since they were sealed, with weights and inference code decrypted into memory only after that chain checks out, and access to the resulting outputs mediated by an interface the buyer's users interact with rather than a shell they can inspect directly. The buyer gets the product's outputs. They do not get a debugger attached to the process producing them.

None of these layers is sufficient alone. Tamper evidence without encryption just tells you the box was opened after your data is already gone. Encryption without integrity verification can be defeated by an attacker willing to try many offline copies of the same drive. The protection is the composition of all three, engineered together rather than bolted on separately. That is the actual discipline behind sealing a build, as opposed to just putting a lock on the case.

Why this has to be engineered per deal, not shipped generically

It would be simpler, in the abstract, to build one hardened enclosure design and drop different ISVs' software into it interchangeably. That is not how the threat model actually works, because what needs protecting is different for every ISV, and the environment the box lands in is different for every buyer.

An ISV whose defensible asset is a fine-tuned model has a different protection surface than one whose defensible asset is a proprietary retrieval pipeline over structured data, which is different again from one whose asset is the orchestration logic tying several models together. What counts as the trade secret, and therefore what the black-box boundary has to wrap tightly around versus what can be more loosely exposed for the buyer's own integration needs, varies by product. And the environment matters just as much: a unit headed for a fixed data-center rack has different physical threat exposure than one headed for a mobile or field deployment, which changes what the enclosure itself needs to withstand before the tamper-evident layer even comes into play.

This is why building an appliance that genuinely protects an ISV's IP is a scoping exercise against one specific deal (this buyer, this environment, this software, this asset worth protecting) rather than a specification pulled off a shelf. Chassis exists to do that scoping and building work: Element 31 takes the ISV's software image, works out with the ISV what inside it actually constitutes the defensible asset, and engineers the physical and cryptographic boundary around that asset specifically, before sealing and shipping a unit that carries the ISV's own brand to the buyer who will hold it.

What the buyer actually gets, and doesn't

It is worth being clear about what this arrangement is not, because the black-box framing can sound adversarial toward the buyer, and it isn't meant to be. The buyer gets exactly what they asked for: full physical custody, no outbound network dependency, no obligation to trust a vendor's cloud infrastructure or a vendor's ongoing access to their environment. Nothing about protecting the ISV's IP takes anything away from that. The buyer runs the workload, gets the outputs, and answers to their own security review with a tamper-evident unit and a verifiable boot chain. The same properties that make the appliance trustworthy to them are the properties that make it safe for the ISV to ship.

What the buyer does not get, and was never promised, is the ability to extract the model weights, read the source, or repurpose the software outside the terms of the deal. That was never the buyer's ask in the first place. Secure-facility buyers are not typically trying to reverse-engineer their vendors. They are trying to run a workload without a network dependency they cannot accept. A well-built black box satisfies that requirement and the ISV's requirement at the same time, because the two requirements, looked at honestly, were never actually pointed at each other.

The trade this makes possible

The practical effect is that physical possession stops being the thing an ISV has to fear about air-gapped deals. An ISV can put its most valuable asset (the model, the pipeline, the accumulated tuning) into a box, hand that box to a buyer it may never get physical access to again, and have reasonable engineering grounds to believe the asset is still protected. That is a different posture than hoping the buyer behaves well, or relying on a contract's confidentiality clause to do work that only hardware and cryptography can actually do. The contract still matters. It just isn't carrying the whole weight by itself anymore.