Comparing Approaches to Secure LLM Deployment
There are three ways to deploy an LLM securely in a regulated environment: a hosted API with security add-ons, a VPC / private-cloud deployment, and an air-gapped on-prem deployment. The one that matters most to a pharma or federal buyer is the one where the security controls can be independently verified on hardware the buyer controls — not taken on the vendor's word. Only air-gapped on-prem clears that bar for all four controls that matter.
This page is a diligence framework, not a sales pitch. It scores each approach against four controls a regulated buyer can, in principle, verify: weight provenance, capacity enumeration, no egress, and a signed audit chain. Use it to interrogate any vendor — including us. The right question is never "is it secure?" It is "which of these controls can I check myself, and which am I trusting you on?"
The four controls we compare against
Every approach below is measured against the same four controls. The distinction that separates them is not whether a control exists on paper, but whether you can verify it on your hardware, or whether you are reading a vendor's report about it.
- Provenance — are the weights in memory proven byte-identical to the public artifact you approved, so nothing was swapped or silently updated?
- Capacity — is the model's dormant / latent capacity enumerated and disclosed, so what it could do is a known quantity?
- No egress — is there genuinely no route to the internet and no name to resolve? Things go in; nothing comes out.
- Signed audit chain — is every inference call anchored to a tamper-evident chain signed with post-quantum cryptography (ML-DSA), verifiable by you?
The three approaches
Hosted API with security add-ons
A commercial model API — proprietary weights you never see — wrapped in governance features: request logging, private networking endpoints, a data-processing agreement, sometimes a compliance certification. The model still runs on the provider's infrastructure, and inference traffic leaves your perimeter to reach it.
This is the fastest to stand up and the weakest on independent verification. Provenance is impossible in principle: the weights are closed, so you cannot hash them against a public artifact. No-egress is definitionally false — the whole architecture depends on egress to the API. The audit trail is an export you read, not a chain you cryptographically verify.
Verifiable by you: essentially none of the four. You are trusting the provider's attestation and contract.
VPC / private cloud
The model runs on cloud infrastructure inside your own virtual private cloud or a dedicated tenant. Data stays in your chosen region, network isolation is strong, and you can often bring an open-weight model you control. This is a real improvement — regulated data need not traverse the public internet.
But the hardware is still the provider's, and a control plane still reaches into the environment for orchestration, patching, and billing. You can inspect a great deal, yet the final answer to "is there truly no route out?" and "did the weights and the audit record survive untampered?" rests partly on the provider's isolation guarantees and shared-responsibility model. You verify the configuration; you trust the substrate.
Verifiable by you: partial. Provenance is possible with open weights; no-egress and the audit chain are constrained by the provider's control plane.
Air-gapped on-prem — the Hyfstele model
An open-weight model runs inside your own perimeter, on hardware you possess, with no route to the internet. Because you hold the machine, every control resolves to a check you run yourself rather than a report you read. This is the approach Hyfstele takes.
Provenance: hash the loaded weights, compare byte-for-byte to the published public artifact. Capacity: review the enumeration against the model you are actually running. No egress: inspect network policy and DNS on the host — no route, no name. Audit chain: verify the ML-DSA post-quantum signatures over the linked inference records, locally.
Verifiable by you: all four, on hardware you control. Evidence, not the vendor's word.
Side by side: who can verify what
The columns are the three approaches; the rows are the four controls plus the two regulatory-fit questions a regulated buyer will be asked in an audit. Read each cell as "can the buyer verify this independently, on hardware they control?"
| Control | Hosted API + add-ons | VPC / private cloud | Air-gapped on-prem |
|---|---|---|---|
| Provenance byte-identical weights |
NOClosed weights; nothing to hash against a public artifact. | PARTIALPossible with open weights you bring, but load path sits on provider hardware. | YESHash loaded weights vs. public artifact, on your machine. |
| Capacity latent capability enumerated |
NOModel internals are the provider's; not disclosed to you. | PARTIALDepends on running a model whose weights you can inspect. | YESEnumeration reviewed against the exact model you run. |
| No egress no route out, no name |
NOEgress to the API is the architecture; data leaves the perimeter. | PARTIALStrong isolation, but a provider control plane still reaches the tenant. | YESInspect network policy and DNS on the host: no route, no name. |
| Signed audit chain tamper-evident, ML-DSA |
NOAudit export you read; not a chain you cryptographically verify. | PARTIALLogging is strong, but integrity rests on the provider's substrate. | YESVerify post-quantum signatures over linked records, locally. |
| Data residency where regulated data lives |
WEAKData leaves your perimeter to reach the provider. | GOODStays in your region, but on the provider's infrastructure. | TIGHTESTNever leaves your perimeter; no egress path exists. |
| Part 11 audit-trail fit attributable + tamper-evident |
WEAKUnverifiable export is weaker evidence for an inspector. | GOODSolid logging; integrity depends on provider guarantees. | STRONGESTSigned chain you verify yourself; attributable per inference. |
PARTIAL is not a failing grade. VPC is a defensible choice when on-prem hardware is impractical and the buyer accepts the provider's shared-responsibility boundary. The point of the table is precise: it marks where a control becomes your evidence versus the vendor's attestation, so you can decide with eyes open which controls you are willing to trust rather than check.
Data residency and 21 CFR Part 11 fit
Two obligations dominate regulated diligence, and the approaches diverge sharply on both.
Data residency. A hosted API moves regulated data to the provider to get an answer back. VPC keeps data in your chosen region but on the provider's infrastructure. Air-gapped on-prem keeps it entirely inside your perimeter — there is no egress path, so residency is a physical fact rather than a contractual promise. For data whose movement is itself a regulated event, the difference between "contractually confined" and "physically cannot leave" is the difference an auditor cares about.
21 CFR Part 11. Part 11 asks that electronic records be attributable, tamper-evident, and auditable. The decisive question is the strength of the audit-trail evidence. An export you cannot independently verify is trust; a chain whose post-quantum ML-DSA signatures you verify on your own hardware is proof. GxP process control adds a second demand — the exact validated model version must be pinned and provable — which is precisely what byte-identical weight provenance delivers, and which closed hosted APIs cannot.
A diligence framework, not a marketing pitch
Take these five questions into any vendor conversation. For each, the only answer that counts is whether you can run the check on hardware you control.
- Provenance. Can I hash the deployed weights and match them byte-for-byte to a public artifact — or are the weights closed?
- Capacity. Is the model's dormant / latent capacity enumerated and disclosed for the exact model I run?
- No egress. Can I prove there is no network route out and no name to resolve, by inspecting the host myself?
- Audit chain. Is every inference anchored to a tamper-evident chain whose signatures I verify locally, using cryptography that survives future attacks (post-quantum)?
- Residency. Does regulated data physically stay inside my perimeter, or is it confined only by contract?
None of these approaches — ours included — proves the model is clean. We do not claim the model is safe or backdoor-free, and we do not claim to have scanned it. No one can honestly certify a large model is free of hidden behavior. What a comparison can honestly do is rank approaches by which controls the buyer can verify versus trust. That is the whole game: constrain what a model can do, prove what it did, and put the evidence in your hands. Evidence you can check on your own hardware — not our word.
Where Hyfstele sits
Hyfstele is the air-gapped on-prem approach: open-weight models inside your perimeter with all four controls verifiable on your own hardware. The current live proof point is an assist for pharmaceutical MLR (Medical, Legal, Regulatory) promotional review, demoable at mlr.hyfstele.com.
Its doctrine is deliberate: the system flags potential issues, a qualified human judges, and every step is proven on the signed audit chain. There is no LLM inside the flag decision plane — the model surfaces candidates, but the logic that determines a flag is deterministic and reviewable. In short: "It flags. You decide."
Frequently asked questions
What are the main approaches to secure LLM deployment?
Three: a hosted API with security add-ons (a commercial model API wrapped in governance features), VPC / private cloud (the model runs inside your virtual network on provider hardware), and air-gapped on-prem (an open-weight model inside your own perimeter with no internet route). They differ most in whether you can verify controls yourself or must trust a vendor.
Which approach allows independent verification on my own hardware?
Only air-gapped on-prem, for all four controls, because you possess the machine — you hash the weights, inspect the network, and verify the audit-chain signatures yourself. Hosted-API and VPC deployments can be well isolated, but their core controls resolve partly or wholly to the provider's attestation rather than your own check.
How do the approaches fit 21 CFR Part 11 and data residency?
For Part 11, what matters is whether the inference audit trail is attributable, tamper-evident, and independently verifiable — a signed chain you check beats an export you cannot. For residency, air-gapped on-prem keeps regulated data physically inside your perimeter with no egress path, which is a stronger fit than data confined only by contract.
Does any of this prove the model is clean or backdoor-free?
No. We do not claim the model is clean, safe, or backdoor-free, and we do not claim to have scanned it. The honest comparison is about which verifiable controls each approach offers — provenance, capacity, no egress, signed audit — not about certifying a model's internals.
What should I ask a vendor during diligence?
For each of the four controls plus data residency, ask a single question: can I run the check myself on hardware I control, or am I reading your report? An approach that answers "you verify it yourself" to all of them is materially stronger evidence for an auditor than one that answers "trust our attestation."
Run the four controls against your own use case
Walk the MLR assist, or bring a regulated workload and we will show the evidence trail on hardware you control.
Talk to Hibiscus Consulting See the live MLR demo