Secure LLM Deployment Defined by Four Verifiable Controls

A secure LLM deployment runs open-weight models inside your own perimeter, air-gapped, under four controls you can verify on your own hardware — not four claims you have to take on a vendor's word. Those controls are: byte-identical weight provenance, dormant-capacity enumeration, no egress, and a tamper-evident signed audit chain. It is a posture defined by evidence, not assurance.

Most "secure AI" pitches are a governance dashboard bolted onto someone else's API: visibility after the fact, optional approval, an audit export you cannot independently check. That is trust, not security. A secure LLM deployment inverts it. The model runs where your data already lives, cut off from the network, and each of the four controls resolves to a check you run against your own machine. The output of that check is the security property — not our attestation of it.

The four controls

Each control is independent, and each is verifiable on the customer's hardware. Together they define what "secure" means for a language model in a regulated environment.

1. Byte-identical weight provenance

   The weights loaded into memory are proven byte-for-byte identical to the public artifact you approved. Nothing was swapped, fine-tuned in the dark, or silently updated between approval and inference.

   VERIFY: hash the loaded weights, compare to the published artifact hash.

2. Dormant / latent capacity enumerated

   The capabilities present in the model — including capacity that is dormant until triggered — are enumerated and disclosed, so what the model could do is a known quantity rather than a surprise in production.

   VERIFY: review the capacity enumeration against the model you are running.

3. No egress

   There is no route to the internet and no name to resolve. Things go in; nothing comes out. Regulated data cannot leave the perimeter and the model cannot phone home, because there is nowhere for a packet to go.

   VERIFY: inspect network policy and DNS resolution on the host — no route, no name.

4. Tamper-evident signed audit chain

   Every inference call is anchored to a linked, tamper-evident audit chain signed with post-quantum cryptography (ML-DSA). Any alteration to the record of what ran breaks the signature and is detectable.

   VERIFY: check the ML-DSA signatures over the linked inference records.

Who needs this

Secure LLM deployment is for buyers whose obligations generic cloud AI cannot meet — chiefly pharmaceutical and federal organizations:

• 21 CFR Part 11 — electronic records and signatures must be attributable, tamper-evident, and auditable. The signed audit chain produces exactly that record for every inference.
• GxP — good-practice process control requires the exact validated model version to be pinned and provable. Byte-identical weight provenance makes the version a fact, not an assumption.
• Data residency — regulated data must not leave the perimeter. No egress means there is no path for it to.
• Model provenance — auditors and inspectors ask what model produced a result and whether it could have changed. Provenance plus a signed chain answers both.

The live proof point: MLR assist

The approach is not a whitepaper. The Hyfstele MLR assist is a working deployment for pharmaceutical MLR (Medical, Legal, Regulatory) promotional review, with a live demo at mlr.hyfstele.com. Its operating doctrine is deliberate:

The system flags potential issues in promotional material; a qualified human judges; and every step is proven on the signed audit chain. Critically, there is no LLM inside the flag decision plane — the model surfaces candidates, but the decision logic that determines what counts as a flag is deterministic and reviewable. The doctrine is short: "It flags. You decide." The accountable reviewer stays in control, and the record of every call is captured for audit.

Frequently asked questions