# Teaching Script — Module FT22: Government, Military, and Air-Gapped Deployment

**Course**: Course 3 — LLM Fine-Tuning Masterclass
**Module**: FT22 — Government, Military, and Air-Gapped Deployment
**Duration**: ~50 minutes spoken (75-minute module with lab and discussion)
**Format**: Verbatim transcript with `[SLIDE N]` cues. Read aloud or use as speaker notes.

---

[SLIDE 1 — Title]

Welcome to module FT twenty-two — Government, Military, and Air-Gapped Deployment. This is Pillar seven, the Sensitive Domains pillar, and it is the partner to FT twenty-one on HIPAA. Where FT twenty-one made the open-data argument for healthcare, this module makes the same argument for government and defense — and then layers on two things healthcare mostly does not have to worry about: a formal classification ladder, the DoD Impact Levels, and the air-gapped deployment architecture that the highest of those levels demands.

If you have not taken FT twenty-one yet, go back. The open-data argument there generalizes directly, and I will assume it. If you have not taken FT twenty, the serving module, go back too — this module's air-gap design depends on the llama-dot-cpp and vLLM stacks from FT twenty.

[SLIDE 2 — The thesis, restated for this tier]

Here is the thesis, restated for the government tier. FedRAMP authorizes the cloud service. It does not authorize the weights. Read that twice.

A FedRAMP Moderate authorization means the cloud provider passed roughly three-hundred-twenty-five controls — physical security, personnel clearance, audit logging, incident response. It says nothing — structurally nothing — about whether the neural network weights you load into that cloud are trustworthy. It says nothing about what the model was trained on. It says nothing about whether the LoRA adapter you merged in last Tuesday has a backdoor.

At IL5 and above — and especially on air-gapped JWICS — that gap is the entire module. You must be able to audit three things: the model's weights, the model's training data, and the supply chain that produced the artifact you load. The first two force the open-data choice. The third forces the defensive playbook. Let's take them in order.

[SLIDE 3 — DoD Impact Levels, the ladder]

The DoD Impact Levels are the compliance ladder every government AI deployment climbs. The framework was built by DISA, the Defense Information Systems Agency, and it is the canonical reference cited by GSA, FedRAMP, Microsoft, StackArmor, and Second Front Systems.

Bottom to top. IL2 is FedRAMP Moderate, roughly three-hundred-twenty-five controls. Unclassified but non-public information. NIPRNet, the unclassified network. This is where administrative workloads live — HR, logistics, internal comms.

IL4 is Moderate plus the DoD overlays. This is where CUI enters — Controlled Unclassified Information. Export-controlled technical data, PII, law-enforcement-sensitive material. CUI is where most of the operational DoD AI appetite actually lives. NIPRNet still.

IL5 is FedRAMP High. CUI and national-security systems. NIPRNet or SIPRNet. This is where the open-data argument becomes load-bearing.

IL6 is High plus the classified overlays. SECRET. SIPRNet. Dedicated or classified cloud.

And IL7 and above — TS and SCI — is beyond FedRAMP entirely. JWICS. Air-gapped. There is no commercial cloud authorization that applies. The model must arrive on media, be verified on media, and run on local hardware.

Two facts to fix in memory. First, FedRAMP authorizes the cloud service, not the model. Second, IL7-plus is, by construction, beyond commercial cloud. There is no pull from Hugging Face on JWICS. There is no API call to an inference provider. That is the design point.

[SLIDE 4 — Why IL5/IL6 demand open-data]

Now the structural argument. At IL5 and above you must be able to audit the model's weights AND its training data. Three properties follow, and they are non-negotiable.

First, reproducibility. You should be able, in principle, to re-derive the model from its published training corpus and code. You will not actually re-run a trillion-token pretraining run on JWICS — that is not the point. The point is that the fact you could is what makes the model auditable. A closed-weight model gives you none of this. You are trusting the publisher's attestation that nothing untoward happened during training. At IL5-plus, attestation is not a control.

Second, no hidden training-time exfiltration. A closed-weight model trained on a private cluster could, in principle, have been trained on data that includes sensitive material you cannot see, or have had its behavior shaped by a process you cannot inspect. Open-data models publish their corpus. You can diff it against known sources and flag anything anomalous.

Third, no embedded behavior you cannot account for. This is where the mechanistic-interpretability toolkit from module seventeen — abliteration — gets reused defensively. The same diff-in-means technique that finds the refusal direction so you can delete it, offensively, also finds unexpected steering directions a backdoor would have implanted, defensively. But that probing is only meaningful if you have a reference — the open-data training corpus that tells you what the model should have learned.

So: open-data — MiniCPM, OLMo, Tülu, SmolLM3 — is required at IL5-plus. Open-weights-only, like Llama three, is acceptable at IL2 through IL4 with documented due diligence and a liability at IL5-plus. Closed-weight is API-only and incompatible with air-gap, full stop.

There is a corollary that catches most teams. Community merges and LoRAs are a non-starter unless you can re-derive them. A community-merged model on Hugging Face — some Llama-three-Smaug-OpenHermes-blend-version-four — is a chain of merges and LoRA applications whose provenance you cannot reconstruct. Even if every link is well-intentioned, you cannot re-derive it from source. At IL5-plus, an unauditable artifact is a contraband artifact. The rule: if you cannot fully re-derive an artifact from its published source weights and training recipe, you may not load it into an IL5-plus environment. It is harsh. It rules out the overwhelming majority of quote-open community models. It is also correct.

[SLIDE 5 — Open-data vs open-weights vs closed]

The model-type choice, in one table. Open-data — weights and corpus — MiniCPM, OLMo, Tülu, SmolLM3 — required at IL5-plus. Open-weights-only — weights, no data — Llama three, Mistral — IL2 through IL4 with due diligence. Closed-weight — OpenAI, Anthropic, Gemini — API-only, incompatible with air-gap. The slide says it all; the load-bearing point is that auditability is a deployment requirement at IL5-plus, not a preference.

[SLIDE 6 — The LoRA / merge supply-chain risk]

Now the attack surface. OWASP, the Open Worldwide Application Security Project, revised its LLM Top Ten in twenty-twenty-five. Entry LLM-zero-three is Supply Chain Vulnerabilities. And it is unusually specific for an OWASP document. It does not speak in generalities about third-party dependencies. It names, as a first-class attack vector — and I am quoting — "an attacker infiltrates a third-party supplier and compromises the production of a LoRA adapter, or a model-merge pipeline, such that the resulting artifact behaves normally under test but activates malicious behavior under a trigger known to the attacker."

That is the first time a major standards body has explicitly named LoRA adapters and model merges as a supply-chain attack surface on par with vulnerable packages and poisoned data. OWASP enumerates three core risks: poisoned models — a base, adapter, or merge backdoored at the weight level; vulnerable packages — the transformers, peft, trl, safetensors, bitsandbytes dependency tree, which is subject to the same PyPI and npm typosquatting and account-takeover incidents as any other Python ecosystem; and weak provenance — no signed manifests, no pinned mirrors, no checksum verification.

[SLIDE 7 — The LoRA-specific backdoor research]

The threat is not theoretical. Five lines of recent work establish that LoRA adapters are a uniquely attractive backdoor substrate, because they are small, swappable, and trusted by assumption.

arXiv twenty-five-twelve-one-nine-two-nine-seven, Causal-Guided Detoxify Backdoor on LoRA adapters. Demonstrates a backdoor that survives the normal safety-eval pipeline by appearing to improve the model on benchmark dimensions — the adapter looks like a benign detoxify fine-tune — while implanting a trigger-conditioned misbehavior. A defensive reviewer running standard benchmarks sees a better-behaving model.

MasqLoRA, CVPR twenty-twenty-six. The first systematic framework for LoRA supply-chain backdoors. The contribution is the taxonomy. It shows that an attacker who controls the adapter can implant backdoors that survive quantization, survive merging into the base, and evade diff-based detection because the malicious update is rank-compatible with the legitimate one. The "Masq" in the name is the key insight — the malicious LoRA masquerades as a legitimate one at every level of inspection short of activation probing.

Down the Rabbit Hole of Backdoors, an OpenReview survey. Compositional risk — a backdoor in adapter A can be activated by a different trigger when A is merged with adapter B, even if B is benign. The community-merge supply chain is not a sum of independent risks; it is a multiplicative risk surface.

Anthropic's small-samples-poison research, with related work — a very small number of poisoned samples can implant backdoors regardless of model scale. The implication is grim for the "we trained on a huge clean corpus, so a few bad rows don't matter" intuition. At the fine-tuning stage, even single-digit-percentage poison rates can produce reliable trigger-conditional behavior. Scale does not buy you immunity. The defense is not more data; the defense is verified data.

And a PMC review of clinical LLM deployment names what it calls LoRA's double vulnerability — clinical fine-tuning attacks both the data, poisoned patient records, and the adapter, a malicious LoRA distributed as a medical-reasoning enhancement. Healthcare and defense share this exposure. The framing worth memorizing: in adapter-based fine-tuning, the data and the adapter are independent attack surfaces, and either is sufficient to compromise the model.

[SLIDE 8 — The defensive playbook, five steps]

Here is how you verify a model you did not train. Five steps. Apply in order. Skip none at IL5-plus.

Step one. Prefer open-data models. This is the gating decision. MiniCPM, OLMo, Tülu, SmolLM3. Weights and corpus published. At IL2 through IL4 you can defend open-weights-only with documented due diligence; at IL5-plus you cannot defend it without extraordinary mitigations.

Step two. Re-derive quants and LoRAs from source. Do not trust an opaque community quant — some model dash Q4 underscore K underscore M dot GGUF uploaded by anonymous user forty-seven. Take the published source weights, apply the published quantization recipe yourself using pinned toolchain versions. For LoRAs, either train your own or require that a third-party adapter's training data and recipe are published so you can re-derive it. This eliminates the entire poisoned-quant and poisoned-adapter attack class by removing the opaque artifact from the trust chain.

Step three. Diff-in-means, activation probing. Reuse the mechanistic-interpretability toolkit from module seventeen, pointed inward. Build contrastive prompt pairs — trigger present versus trigger absent — across a sweep of candidate triggers, compute the mean activation difference at each residual-stream layer, and look for directions that activate strongly on the trigger but are near-zero on benign inputs. A clean model has a small, interpretable set of salient directions — refusal, format, language. A backdoored model has extra directions that correspond to no documented training signal. This is the only detection method that survives the MasqLoRA attack class, because MasqLoRA is explicitly designed to evade weight-diff inspection.

Step four. Behavioral evals before deployment. Promptfoo for prompt-injection, jailbreak, and policy-violation coverage. Garak, NVIDIA's LLM vulnerability scanner, for the known-probe catalog. And your own domain-specific adversarial suite. Behavioral evals are necessary but not sufficient — they catch known failure modes and obvious backdoors. They do not catch a MasqLoRA-style attack designed to evade benchmarks. That is why step three exists.

Step five. Checksum and signature verification, and a pinned internal mirror. Never HF-pull directly from Hugging Face in a production or classified path. The trust boundary is: pull at an inbound gate — a network-connected staging host, not the deployment host — record the hash, sign it with your organization's key, store it in your internal mirror. Transfer it on one-way media for air-gap, or over a verified internal network for IL2 through IL6. Verify on load — recompute the hash, verify the signature against your org key, refuse to load if either check fails. This converts "we trust Hugging Face" into "we trust our own signing infrastructure, and we trust Hugging Face only at the inbound gate where we can inspect."

[SLIDE 9 — Air-gapped deployment, the four verbs]

Now the deployment architecture. Air-gapped deployment is not deployment with the network turned off. It is a distinct architecture with a distinct threat model. The assumption is that nothing may traverse the boundary at runtime — not a model download, not a telemetry ping, not an OAuth refresh. Four verbs.

Pre-load. Every artifact the deployment will ever need — base weights, tokenizer config, system prompt, eval harness, dependency tree — loaded onto the deployment host before the network is severed. This is the inbound-gate workflow from step five, with the addition that the gate is a physically separate machine.

Sever. After pre-load, the network interface is disabled or removed. Verification: ip link show returns no carrier, no default route exists, DNS is unresolvable, no outbound SYN has been observed for the deployment's lifetime. Testable, and tested continuously.

Bind. The inference server binds to one-twenty-seven-dot-zero-dot-zero-dot-one, loopback, or a Unix domain socket — never to zero-dot-zero-dot-zero-dot-zero. The harness is co-located on the same host or talks to the model over a loopback socket. There is no remote inference endpoint, because there is no network to serve it on.

Log. Audit logs written to local append-only storage — and, where policy requires, to a separate one-way-out write appliance. Every prompt, every generation, every model load, every config change is logged. The log is the regulator's evidence that the deployment behaved as authorized.

And here is where the choices from module twenty pay off. The two production-grade open inference stacks — llama-dot-cpp and vLLM — share a property that matters enormously for air-gap: minimal network posture. llama-server is a single static binary. No container registry, no orchestrator, no service mesh. It binds to loopback by default. It is the most auditable inference server in the ecosystem. vLLM is more complex but still a single-process server with a defined API surface. With a pinned mirror and a frozen requirements file, it is auditable. Neither of these is true of the hosted-model alternatives. An API call to a closed-weight provider is, by construction, a network egress — incompatible with air-gap. The open-weights stack is not a cost-saving choice at IL7-plus; it is the only choice that satisfies the architecture.

[SLIDE 10 — The CDAO closed-vendor gap]

Now the political-economy reality. In late twenty-twenty-four and through twenty-twenty-five, the DoD's Chief Digital and Artificial Intelligence Office, CDAO, announced a slate of frontier-model partners for non-combatant-command use. Anthropic. Google. OpenAI. xAI. Every one of these is a closed-weight vendor. The models are accessed via API. The weights are not published. The training data is not published.

This is not a criticism of CDAO's choices. At the time, the closed-weight vendors were the capability leaders, and operational commanders needed capability. But it is a structural gap, and it is the gap this course exists to address. If every authorized government model is closed-weight, then every government model is unauditable at the weight level, and every IL5-plus or air-gapped deployment is impossible by construction — because you cannot put a closed-weight model on JWICS.

The open-weights response is not "open models are as good as closed models today." They are not, in general. The response has three parts. First, open-data models are auditable in a way closed models structurally cannot be. At IL5-plus and on JWICS, that auditability is a deployment requirement, not a preference. Second, the capability gap is closing. Open frontier-class models are within striking distance of closed-weight capability on most operational tasks. The fine-tuning techniques in this course exist to close the residual gap on your specific task. Third, the supply chain is the attack surface. A closed-weight API you cannot inspect is a trust dependency on the publisher. An open-data model you have verified is a trust dependency on your own process. Defense organizations have a strong prior toward the second. The NTIA's twenty-twenty-four AI Open-Model Weights Report is the U-S government's own acknowledgment of this — it explicitly notes that open-weight models enable sensitive-domain use cases that closed models cannot serve. This module is the engineering-side reading of that report.

[SLIDE 11 — Anti-patterns]

Four anti-patterns to leave with.

First, trusting community merges for classified work. A merged community model whose provenance you cannot reconstruct, loaded into an IL5-plus environment. Violates the re-derivability rule and exposes you to the entire MasqLoRA attack class. The merge looks fine on benchmarks. The backdoor activates on a trigger you did not test.

Second, pulling directly from Hugging Face in production. HF-pull on the deployment host, inside the trust boundary. Even if the artifact is benign today, you have no guarantee it will be benign tomorrow — the hub is mutable, accounts are compromised regularly, and your deployment has no way to detect a swap. Always pull at an inbound gate, sign, mirror, verify on load.

Third, no behavioral evals before deployment. "We ran the model on our task and it worked, so we shipped it." Standard task-eval coverage is roughly zero percent of the adversarial surface. Promptfoo and Garak exist for a reason; run them every time, on every artifact, before any IL4-plus load.

Fourth, assuming open means safe. Open-weights is a necessary condition for auditability at IL5-plus; it is not sufficient. An open-weights model with a poisoned LoRA merged in is open and backdoored. Open-data raises the floor — you can audit the corpus — but you still owe the five-step defensive playbook. "It is open source" is not a security argument. It is the precondition for making a security argument.

[SLIDE 12 — The synthesis with this course]

This is where the module comes together. The open-data model is auditable. The open-weights stack is air-gap-able. The fine-tuning in this course is what closes the residual capability gap on your specific task. Put together: a fine-tuned open-data model, re-derived from source, probed and evaled, signed and mirrored, pre-loaded onto an air-gapped host and bound to loopback — running inside the harness from Course one.

The model steers; the harness bounds. At IL5-plus, both are auditable — because you chose open-data and verified the supply chain. That is the destination of this pillar.

[SLIDE 13 — What you can now do]

You can now recite the DoD Impact Levels and map each to baseline, data class, and network. You can explain why IL5, IL6, and JWICS force the auditable open-data choice. You can name the LoRA supply-chain risk and its three core vectors. You can apply the five-step defensive playbook to any model you did not train. You can design an air-gapped deployment — pre-load, sever, bind, log. And you can place the CDAO closed-vendor gap in the context of the open-weights response.

The lab for this module is the Air-Gap Checklist. No GPU — it is a deployment-design lab. You produce a complete checklist for placing a fine-tuned model into an air-gapped IL5-equivalent environment, covering model provenance, quantization reproducibility, network severance, local serving bind, and audit logging. That checklist is the deliverable you would hand a deployment authority.

Next, module FT twenty-three — Synthesis: Uncensor the Model, Harness the Model. The course's destination. A steered model inside a bounding harness, auditable end to end. Let's get there.

---

*End of module FT22. Duration: approximately fifty minutes spoken at one-hundred-forty words per minute; the full seventy-five-minute module includes the Air-Gap Checklist lab and discussion.*