Module FT22 — Government, Military, and Air-Gapped Deployment

Course: Course 3 — LLM Fine-Tuning Masterclass Module: FT22 — Government, Military, and Air-Gapped Deployment Duration: 75 minutes Level: Senior Engineer and above Prerequisites: FT21 — HIPAA and BAA Elimination (the open-data argument generalizes)

Learning Objectives

After completing this module, you will be able to:

Recite the DoD Impact Levels table (IL2 through IL7+) and map each level to its FedRAMP baseline, data sensitivity class (CUI / SECRET / TS / SCI), and network (NIPRNet / SIPRNet / JWICS).
Explain why IL5/IL6 and air-gapped JWICS demand an auditable open-data model — and why standard FedRAMP cloud authorizations do not directly transfer to the model itself.
Articulate the LoRA / merge supply-chain risk: name OWASP LLM03:2025, the LoRA-specific backdoor research (Causal-Guided Detoxify, MasqLoRA, "Down the Rabbit Hole"), and Anthropic's small-samples-poison finding.
Apply the five-step defensive playbook for verifying a model you did not train (open-data preference, source re-derivation, diff-in-means probing, behavioral evals, checksum/pinned-mirror).
Design an air-gapped deployment: pre-load, sever network, bind locally, log everything — and justify why the llama.cpp / vLLM stacks from FT20 are the right substrate.
Recognize the CDAO vendor-reality gap (closed-weight partners) and place it against the open-weights curriculum response.

22.1 — The DoD Impact Levels

The compliance ladder every government AI deployment climbs. Misplace a workload on it and you have a reportable incident.

The U.S. Department of Defense categorizes information and the systems that process it by Impact Level (IL). The framework was built by DISA (Defense Information Systems Agency) and is the canonical reference cited by GSA, FedRAMP, Microsoft, StackArmor, and Second Front Systems when discussing cloud authorization for government workloads. For an LLM deployment, the IL determines four things at once: which FedRAMP baseline applies, what kind of data you may put in the prompt, which network the box may sit on, and whether the deployment is network-connected or air-gapped.

The table

IL	FedRAMP baseline	Data class	Network	Cloud posture
IL2	FedRAMP Moderate (~325 controls)	Unclassified, non-public	NIPRNet	Authorized commercial cloud
IL4	Moderate + DoD overlays	CUI (Controlled Unclassified Information)	NIPRNet	Cloud with DoD-specific overlays
IL5	FedRAMP High	CUI / National Security Systems	NIPRNet / SIPRNet	High-impact authorized cloud
IL6	High + classified overlays	SECRET	SIPRNet	Dedicated / classified cloud
IL7+	Beyond FedRAMP	TS / SCI	JWICS (air-gapped)	Standalone, air-gapped

Read the table as a ladder of escalating trust requirement, not as a menu. IL2 is where most non-public administrative workloads sit (HR, logistics, internal comms that are not classified but are not for public release). IL4 introduces CUI — anything from export-controlled technical data to PII to law-enforcement-sensitive material; this is where most of the operational DoD AI appetite actually lives. IL5 raises the bar to FedRAMP High and admits national-security data. IL6 is classified SECRET and lives on SIPRNet. IL7 and above — TS and SCI — are the air-gapped tier, served by JWICS, where standard commercial cloud authorizations no longer apply at all.

Two structural facts to fix in memory:

FedRAMP authorizes the cloud service, not the model. A FedRAMP Moderate authorization means the cloud provider's controls pass ~325 controls. It says nothing about whether the weights you load into that cloud are trustworthy, what the model was trained on, or whether the LoRA you merged in has a backdoor. That gap is the subject of this module.

IL7+ is, by construction, beyond commercial cloud. JWICS is air-gapped from the public internet. There is no pull from Hugging Face. There is no API call to an inference provider. The model must arrive on media, be verified on media, and run on local hardware. This is the design point that makes the open-weights stack (Modules FT19–FT20) not a hobbyist choice but a national-security choice.

22.2 — Why IL5/IL6 and Air-Gapped JWICS Demand Auditable Open-Data

The structural argument for open-data models (MiniCPM, OLMo, Tülu) over open-weights-only. The most important paragraph in this module.

Standard FedRAMP cloud authorizations apply to the provider's controls — physical security, personnel clearance, audit logging, incident response. They do not, and structurally cannot, certify the behavioral content of a neural network's weights. A model is trillions of floating-point numbers. There is no FedRAMP control that says "the publisher must prove no training-time exfiltration occurred." There is no IL6 overlay that says "the refusal direction was not adversarially shifted."

This produces a sharp requirement for IL5/IL6 and air-gapped deployments:

You must be able to audit the model's weights AND its training data.

Three properties follow, and they are non-negotiable at these impact levels:

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 — but the fact that 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+, attestation is not a control.
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.
No embedded behavior you cannot account for. This is where the mechanistic-interpretability toolkit from Module FT17 (abliteration) gets reused defensively. If a model has an unexpected steering direction — a latent bias, an implanted trigger, a subtle refusal shift — diff-in-means / activation probing can surface it. 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.

This is the structural argument for open-data over open-weights-only at the sensitive tiers:

Open-data (OpenBMB MiniCPM, Ai2 OLMo and Tülu, HuggingFace SmolLM3): weights and training corpus published. Auditable. The right default for IL5+.
Open-weights-only (Meta Llama 3.x, Mistral, most "open" frontier models): weights published, training data not. You trust the publisher. Acceptable at IL2–IL4 with due diligence; a liability at IL5+.
Closed-weight (OpenAI, Anthropic, Google Gemini): neither weights nor data. API-only. Incompatible with air-gapped deployment by construction.

Community merges and LoRAs are a non-starter (unless re-derivable)

This is the corollary that catches most teams. A community-merged model on Hugging Face — say, a "Llama-3-Smaug-OpenHermes-blend-v4" — is a chain of merges and LoRA applications whose provenance you cannot reconstruct. Even if every link in the chain is well-intentioned, you cannot re-derive it from source. At IL5+, 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+ environment.

This is harsh. It rules out the overwhelming majority of "open" community models. It is also correct, and it is the reason this module spends the next section on the supply-chain risk in detail.

22.3 — The LoRA / Merge Supply-Chain Risk

OWASP named it. The research literature quantified it. Most teams have not internalized it.

OWASP LLM03:2025 — Supply Chain Vulnerabilities

The Open Worldwide Application Security Project's LLM Top Ten, in its 2025 revision, includes LLM03: Supply Chain Vulnerabilities. The entry 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:

"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."

This 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. The three core risks OWASP enumerates:

Poisoned models. A base, adapter, or merge that has been backdoored at the weight level. Behaves normally on benchmarks; misbehaves on a trigger.
Vulnerable packages. The transformers, peft, trl, safetensors, bitsandbytes dependency tree. A compromised release of any of these can silently alter what gets loaded. (Recall the 2024 ultralytics and @stellar/freighter incidents — PyPI/npm typosquatting and account takeover are real, ongoing, and the ML Python ecosystem is not special.)
Weak provenance. No signed manifests, no pinned mirrors, no checksum verification, ambiguous licensing. The artifact could have been swapped on the hub between your test run and your production deploy, and you would not know.

The LoRA-specific backdoor research

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

arXiv:2512.19297 — 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. The "causal-guided" framing matters: the attack is designed to be causally effective at steering the model's behavior in a specific direction, not merely correlated with it. A defensive reviewer running standard benchmarks sees a better-behaving model.

MasqLoRA (CVPR 2026). 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 (a) survive quantization, (b) survive merging into the base, and (c) 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.

OpenReview — "Down the Rabbit Hole of Backdoors." A survey-style treatment of how backdoors propagate through the adapter/merge ecosystem. Its central finding is the 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 therefore not just a sum of independent risks; it is a multiplicative risk surface.

Anthropic: small-samples-poison

A separate but compounding line of work, including contributions from Anthropic, has shown that 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 here. The defense is not more data; the defense is verified data — which loops back to the open-data argument in 22.2.

Healthcare-specific: LoRA's "double vulnerability"

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 used as the training set) and the adapter (a malicious LoRA distributed as a "medical reasoning" enhancement). Healthcare and defense share this exposure because both fields consume a high volume of third-party adapters from a community they do not control. The PMC framing is worth memorizing:

In adapter-based fine-tuning, the data and the adapter are independent attack surfaces, and either one is sufficient to compromise the model.

22.4 — The Defensive Playbook (How to Verify a Model You Did Not Train)

Five steps. Apply them in order. Skip none of them at IL5+.

Step 1 — Prefer open-data models

This is the gating decision. If you have a choice, the base should be open-data (MiniCPM, OLMo, Tülu, SmolLM3). You get the weights and the corpus. You can audit. At IL2–IL4 you can defend open-weights-only (Llama 3.x) with documented due diligence; at IL5+ you cannot defend it without extraordinary mitigations. Closed-weight is incompatible with air-gap and is out of scope for this module entirely.

Step 2 — Re-derive quants and LoRAs from source

Do not trust an opaque community quant (SomeModel-Q4_K_M.gguf uploaded by anon_user_47) or an opaque community LoRA. Instead:

Take the published source weights (the FP16 / BF16 checkpoint).
Apply the published quantization recipe yourself (Module FT19) using pinned toolchain versions.
For LoRAs: either train your own (Modules FT08–FT11) or, if consuming a third-party adapter, require that its training data and recipe are published so you can re-derive it. If you cannot re-derive, you cannot use it at IL5+.

This eliminates the entire "poisoned quant" and "poisoned adapter" attack class by removing the opaque artifact from the trust chain.

Step 3 — Diff-in-means / activation probing

Reuse the mechanistic-interpretability toolkit from Module FT17 (abliteration), pointed inward. The same diff-in-means technique that finds the refusal direction so you can delete it (abliteration, offensive use) also finds unexpected steering directions that a backdoor would have implanted (defensive use).

Concretely: build contrastive prompt pairs (trigger present vs. 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 4 — Behavioral evals before deployment

Run the standard red-team battery before any IL5+ load:

Promptfoo for prompt-injection, jailbreak, and policy-violation coverage.
Garak (NVIDIA's LLM vulnerability scanner) for the known-probe catalog.
Your own domain-specific adversarial suite (the trigger candidates from Step 3 become the test cases here).

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 3 exists.

Step 5 — Checksum / signature verification and a pinned internal mirror

Never hf pull directly from Hugging Face in a production or classified path. The trust boundary is:

Inbound gate (a network-connected "staging" host, not the deployment host): pull the artifact, record its hash, sign it with your organization's key, and store it in your internal mirror.
Transfer (one-way media for air-gap; verified internal network for IL2–IL6): carry the signed artifact to the deployment environment.
Verify on load: recompute the hash, verify the signature against your org key, and 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." The mirror is now your supply chain, and it is auditable.

22.5 — Air-Gapped Deployment Design

Pre-load, sever, bind, log. The four verbs of air-gap.

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. The design:

Pre-load. Every artifact the deployment will ever need — base weights, tokenizer config, system prompt, eval harness, dependency tree — is loaded onto the deployment host before the network is severed. This is the inbound-gate workflow from Step 5 above, with the addition that the gate is a physically separate machine.
Sever the network. 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. This is testable and should be tested continuously.
Bind locally. The inference server binds to 127.0.0.1 (loopback) or a Unix domain socket — never to 0.0.0.0. The harness (the application consuming the model) 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 everything. Audit logs are 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.

Why llama.cpp and vLLM are the right substrate

This is where the choices made in Module FT20 pay off. The two production-grade open inference stacks — llama.cpp (GGUF, CPU/Metal/CUDA, single-host) and vLLM (AWQ/FP8, CUDA, high-throughput) — share a property that matters enormously for air-gap: minimal network posture.

llama.cpp's 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 (Python, CUDA, dependency tree) but is still a single-process server with a defined OpenAI-compatible API surface. With a pinned mirror and a frozen requirements.txt, 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+; it is the only choice that satisfies the architecture.

22.6 — The DoD Vendor Reality and the Open-Weights Response

The gap this curriculum exists to close.

In late 2024 and through 2025, the DoD's Chief Digital and Artificial Intelligence Office (CDAO) announced a slate of frontier-model partners for Nayvee-combatant-command use: Anthropic, Google, OpenAI, and xAI, among others. 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 (and the broader open-weights curriculum) exists to address:

If every authorized government model is closed-weight, then every government model is unauditable at the weight level, and every IL5+/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 is:

Open-data models are auditable in a way closed models structurally cannot be. At IL5+ and on JWICS, that auditability is a deployment requirement, not a preference.
The capability gap is closing. Open frontier-class models (the Llama, Qwen, DeepSeek, and open-data families) are within striking distance of closed-weight capability on most operational tasks. The fine-tuning techniques in this course (Pillars 2–5) exist to close the residual gap on your specific task.
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 2024 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, in effect, the engineering-side reading of that report.

Anti-Patterns

Trusting community merges for classified work

A merged community model (Llama-X-OpenHermes-Smaug-vN) whose provenance you cannot reconstruct, loaded into an IL5+ environment. This violates the re-derivability rule (22.2) 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.

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, and verify on load (Step 5).

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 0% of the adversarial surface. Promptfoo and Garak exist for a reason; run them every time, on every artifact, before any IL4+ load. (They are necessary, not sufficient — pair with Step 3 activation probing.)

Assuming "open" means "safe"

Open-weights is a necessary condition for auditability at IL5+; 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's open source" is not a security argument; it is the precondition for making a security argument.

Key Terms

Term	Definition
Impact Level (IL)	DoD's categorization of information and systems by sensitivity, IL2 through IL7+. Determines FedRAMP baseline, allowed data class, and network.
FedRAMP	Federal Risk and Authorization Management Program. Authorizes cloud services against control baselines (Low / Moderate ~325 controls / High). Does not certify model weights.
CUI	Controlled Unclassified Information. Non-classified but sensitive (export-controlled, PII, law-enforcement). The dominant data class at IL4.
NIPRNet / SIPRNet / JWICS	DoD networks: NIPRNet (unclassified), SIPRNet (SECRET), JWICS (TS/SCI, air-gapped).
Open-data model	Weights and training corpus published (MiniCPM, OLMo, Tülu, SmolLM3). Auditable. Required at IL5+.
Open-weights-only	Weights published, training data not (Llama 3.x). Trust the publisher's attestation.
Closed-weight	Neither weights nor data. API-only. Incompatible with air-gap.
OWASP LLM03:2025	Supply Chain Vulnerabilities — explicitly names LoRA adapter and model-merge compromise as a first-class vector.
MasqLoRA	CVPR 2026 framework; first systematic LoRA supply-chain backdoor taxonomy. Survives quantization, merge, and weight-diff.
Diff-in-means probing	Mechanistic-interp technique (FT17 abliteration, used defensively) that finds unexpected steering directions a backdoor would implant.
Inbound gate / pinned mirror	The trust-boundary architecture: pull, sign, mirror, verify-on-load. Never `pull` inside the trust boundary.
NTIA (2024)	U.S. government's AI Open-Model Weights Report; the policy citation for open-weights enabling sensitive-domain use.

Lab Exercise

See 07-lab-spec.md. "The Air-Gap Checklist" — a deployment-design lab (no GPU) producing a complete checklist for placing a fine-tuned model into an air-gapped IL5-equivalent environment: model provenance verification, quantization-reproducibility-from-source, network-severance verification, local-serving bind, and audit-logging spec.

References

Second Front Systems — DoD Impact Levels (IL2–IL6) Guide. The practitioner-facing reference mapping ILs to FedRAMP baselines, data classes, and networks.
StackArmor — FedRAMP and DoD SRG Impact Levels for Cloud. The compliance-architect reference for IL overlays and authorized cloud postures.
DISA / GSA — Cloud Computing Security Requirements Guide (CC SRG). The authoritative DoD source for IL definitions and cloud authorization.
Microsoft — Microsoft Cloud for Government — Impact Levels. Vendor documentation detailing IL2–IL6 support and the IL6 dedicated-cloud offering.
OWASP — LLM03:2025 Supply Chain Vulnerabilities. The Top-10 entry explicitly naming LoRA adapter and model-merge compromise.
arXiv:2512.19297 — Causal-Guided Detoxify Backdoor on LoRA Adapters. Backdoor that appears benign on benchmarks.
MasqLoRA (CVPR 2026) — First systematic LoRA supply-chain backdoor framework. Survives quantization, merge, and weight-diff.
OpenReview — "Down the Rabbit Hole of Backdoors." Survey of compositional backdoor risk in the adapter/merge ecosystem.
Anthropic (and related) — Small-samples-poison research. A small number of poisoned samples can implant backdoors regardless of scale.
PMC review — Clinical LLM deployment and LoRA's "double vulnerability" (data + adapter poisoning).
NTIA (2024) — AI Open-Model Weights Report. The U.S. government policy citation for open-weights enabling sensitive-domain use.
Module FT17 — Abliteration. The offensive use of diff-in-means; this module reuses the same toolkit defensively.
Module FT20 — vLLM and the Serving Stack. The minimal-network-posture inference substrate this module's air-gap design depends on.
Module FT21 — HIPAA and BAA Elimination. The open-data argument for healthcare; FT22 generalizes it to government.

# Module FT22 — Government, Military, and Air-Gapped Deployment **Course**: Course 3 — LLM Fine-Tuning Masterclass **Module**: FT22 — Government, Military, and Air-Gapped Deployment **Duration**: 75 minutes **Level**: Senior Engineer and above **Prerequisites**: FT21 — HIPAA and BAA Elimination (the open-data argument generalizes) --- ## Learning Objectives After completing this module, you will be able to: 1. Recite the DoD Impact Levels table (IL2 through IL7+) and map each level to its FedRAMP baseline, data sensitivity class (CUI / SECRET / TS / SCI), and network (NIPRNet / SIPRNet / JWICS). 2. Explain *why* IL5/IL6 and air-gapped JWICS demand an **auditable open-data** model — and why standard FedRAMP cloud authorizations do not directly transfer to the model itself. 3. Articulate the LoRA / merge **supply-chain risk**: name OWASP LLM03:2025, the LoRA-specific backdoor research (Causal-Guided Detoxify, MasqLoRA, "Down the Rabbit Hole"), and Anthropic's small-samples-poison finding. 4. Apply the five-step defensive playbook for verifying a model you did not train (open-data preference, source re-derivation, diff-in-means probing, behavioral evals, checksum/pinned-mirror). 5. Design an air-gapped deployment: pre-load, sever network, bind locally, log everything — and justify why the llama.cpp / vLLM stacks from FT20 are the right substrate. 6. Recognize the CDAO vendor-reality gap (closed-weight partners) and place it against the open-weights curriculum response. --- # 22.1 — The DoD Impact Levels *The compliance ladder every government AI deployment climbs. Misplace a workload on it and you have a reportable incident.* The U.S. Department of Defense categorizes information and the systems that process it by **Impact Level** (IL). The framework was built by DISA (Defense Information Systems Agency) and is the canonical reference cited by GSA, FedRAMP, Microsoft, StackArmor, and Second Front Systems when discussing cloud authorization for government workloads. For an LLM deployment, the IL determines four things at once: which FedRAMP baseline applies, what kind of data you may put in the prompt, which network the box may sit on, and whether the deployment is network-connected or air-gapped. ## The table | IL | FedRAMP baseline | Data class | Network | Cloud posture | | --- | --- | --- | --- | --- | | **IL2** | FedRAMP **Moderate** (~325 controls) | Unclassified, non-public | NIPRNet | Authorized commercial cloud | | **IL4** | Moderate + **DoD overlays** | **CUI** (Controlled Unclassified Information) | NIPRNet | Cloud with DoD-specific overlays | | **IL5** | FedRAMP **High** | CUI / National Security Systems | NIPRNet / SIPRNet | High-impact authorized cloud | | **IL6** | High + **classified overlays** | **SECRET** | SIPRNet | Dedicated / classified cloud | | **IL7+** | **Beyond FedRAMP** | **TS / SCI** | **JWICS** (air-gapped) | Standalone, air-gapped | Read the table as a ladder of *escalating trust requirement*, not as a menu. IL2 is where most non-public administrative workloads sit (HR, logistics, internal comms that are not classified but are not for public release). IL4 introduces **CUI** — anything from export-controlled technical data to PII to law-enforcement-sensitive material; this is where most of the operational DoD AI appetite actually lives. IL5 raises the bar to FedRAMP High and admits national-security data. IL6 is classified SECRET and lives on SIPRNet. IL7 and above — TS and SCI — are the air-gapped tier, served by JWICS, where standard commercial cloud authorizations no longer apply at all. Two structural facts to fix in memory: > **FedRAMP authorizes the *cloud service*, not the *model*.** A FedRAMP Moderate authorization means the cloud provider's controls pass ~325 controls. It says nothing about whether the weights you load into that cloud are trustworthy, what the model was trained on, or whether the LoRA you merged in has a backdoor. That gap is the subject of this module. > **IL7+ is, by construction, beyond commercial cloud.** JWICS is air-gapped from the public internet. There is no `pull` from Hugging Face. There is no API call to an inference provider. The model must arrive on media, be verified on media, and run on local hardware. This is the design point that makes the open-weights stack (Modules FT19–FT20) not a hobbyist choice but a *national-security* choice. --- # 22.2 — Why IL5/IL6 and Air-Gapped JWICS Demand Auditable Open-Data *The structural argument for open-data models (MiniCPM, OLMo, Tülu) over open-weights-only. The most important paragraph in this module.* Standard FedRAMP cloud authorizations apply to the *provider's* controls — physical security, personnel clearance, audit logging, incident response. They do not, and structurally cannot, certify the *behavioral content* of a neural network's weights. A model is trillions of floating-point numbers. There is no FedRAMP control that says "the publisher must prove no training-time exfiltration occurred." There is no IL6 overlay that says "the refusal direction was not adversarially shifted." This produces a sharp requirement for IL5/IL6 and air-gapped deployments: > **You must be able to audit the model's weights AND its training data.** Three properties follow, and they are non-negotiable at these impact levels: 1. **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 — but the fact that 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+, attestation is not a control. 2. **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. 3. **No embedded behavior you cannot account for.** This is where the mechanistic-interpretability toolkit from Module FT17 (abliteration) gets reused *defensively*. If a model has an unexpected steering direction — a latent bias, an implanted trigger, a subtle refusal shift — diff-in-means / activation probing can surface it. 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. This is the structural argument for **open-data over open-weights-only** at the sensitive tiers: - **Open-data** (OpenBMB MiniCPM, Ai2 OLMo and Tülu, HuggingFace SmolLM3): weights **and** training corpus published. Auditable. The right default for IL5+. - **Open-weights-only** (Meta Llama 3.x, Mistral, most "open" frontier models): weights published, training data not. You trust the publisher. Acceptable at IL2–IL4 with due diligence; a liability at IL5+. - **Closed-weight** (OpenAI, Anthropic, Google Gemini): neither weights nor data. API-only. Incompatible with air-gapped deployment by construction. ### Community merges and LoRAs are a non-starter (unless re-derivable) This is the corollary that catches most teams. A community-merged model on Hugging Face — say, a "Llama-3-Smaug-OpenHermes-blend-v4" — is a chain of merges and LoRA applications whose provenance you cannot reconstruct. Even if every link in the chain is well-intentioned, you cannot re-derive it from source. At IL5+, 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+ environment.** This is harsh. It rules out the overwhelming majority of "open" community models. It is also correct, and it is the reason this module spends the next section on the supply-chain risk in detail. --- # 22.3 — The LoRA / Merge Supply-Chain Risk *OWASP named it. The research literature quantified it. Most teams have not internalized it.* ## OWASP LLM03:2025 — Supply Chain Vulnerabilities The Open Worldwide Application Security Project's LLM Top Ten, in its 2025 revision, includes **LLM03: Supply Chain Vulnerabilities**. The entry 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: > *"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."* This 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. The three core risks OWASP enumerates: 1. **Poisoned models.** A base, adapter, or merge that has been backdoored at the weight level. Behaves normally on benchmarks; misbehaves on a trigger. 2. **Vulnerable packages.** The `transformers`, `peft`, `trl`, `safetensors`, `bitsandbytes` dependency tree. A compromised release of any of these can silently alter what gets loaded. (Recall the 2024 `ultralytics` and `@stellar/freighter` incidents — PyPI/npm typosquatting and account takeover are real, ongoing, and the ML Python ecosystem is not special.) 3. **Weak provenance.** No signed manifests, no pinned mirrors, no checksum verification, ambiguous licensing. The artifact could have been swapped on the hub between your test run and your production deploy, and you would not know. ## The LoRA-specific backdoor research The threat is not theoretical. Three recent lines of work have established that LoRA adapters are a *uniquely attractive* backdoor substrate, because they are small, swappable, and trusted by assumption. **arXiv:2512.19297 — 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. The "causal-guided" framing matters: the attack is designed to be causally effective at steering the model's behavior in a specific direction, not merely correlated with it. A defensive reviewer running standard benchmarks sees a better-behaving model. **MasqLoRA (CVPR 2026).** 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 (a) survive quantization, (b) survive merging into the base, and (c) 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. **OpenReview — "Down the Rabbit Hole of Backdoors."** A survey-style treatment of how backdoors propagate through the adapter/merge ecosystem. Its central finding is the *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 therefore not just a sum of independent risks; it is a multiplicative risk surface. ## Anthropic: small-samples-poison A separate but compounding line of work, including contributions from Anthropic, has shown that **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 here. The defense is *not* more data; the defense is *verified* data — which loops back to the open-data argument in 22.2. ## Healthcare-specific: LoRA's "double vulnerability" 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 used as the training set) and the *adapter* (a malicious LoRA distributed as a "medical reasoning" enhancement). Healthcare and defense share this exposure because both fields consume a high volume of third-party adapters from a community they do not control. The PMC framing is worth memorizing: > **In adapter-based fine-tuning, the data and the adapter are independent attack surfaces, and either one is sufficient to compromise the model.** --- # 22.4 — The Defensive Playbook (How to Verify a Model You Did Not Train) *Five steps. Apply them in order. Skip none of them at IL5+.* ## Step 1 — Prefer open-data models This is the gating decision. If you have a choice, the base should be open-data (MiniCPM, OLMo, Tülu, SmolLM3). You get the weights and the corpus. You can audit. At IL2–IL4 you can defend open-weights-only (Llama 3.x) with documented due diligence; at IL5+ you cannot defend it without extraordinary mitigations. Closed-weight is incompatible with air-gap and is out of scope for this module entirely. ## Step 2 — Re-derive quants and LoRAs from source Do not trust an opaque community quant (`SomeModel-Q4_K_M.gguf` uploaded by `anon_user_47`) or an opaque community LoRA. Instead: - Take the published source weights (the FP16 / BF16 checkpoint). - Apply the published quantization recipe yourself (Module FT19) using pinned toolchain versions. - For LoRAs: either train your own (Modules FT08–FT11) or, if consuming a third-party adapter, require that its training data and recipe are published so you can re-derive it. If you cannot re-derive, you cannot use it at IL5+. This eliminates the entire "poisoned quant" and "poisoned adapter" attack class by removing the opaque artifact from the trust chain. ## Step 3 — Diff-in-means / activation probing Reuse the mechanistic-interpretability toolkit from Module FT17 (abliteration), pointed *inward*. The same diff-in-means technique that *finds* the refusal direction so you can delete it (abliteration, offensive use) also *finds* unexpected steering directions that a backdoor would have implanted (defensive use). Concretely: build contrastive prompt pairs (trigger present vs. 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 4 — Behavioral evals before deployment Run the standard red-team battery before any IL5+ load: - **Promptfoo** for prompt-injection, jailbreak, and policy-violation coverage. - **Garak** (NVIDIA's LLM vulnerability scanner) for the known-probe catalog. - Your own domain-specific adversarial suite (the trigger candidates from Step 3 become the test cases here). 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 3 exists. ## Step 5 — Checksum / signature verification and a pinned internal mirror Never `hf pull` directly from Hugging Face in a production or classified path. The trust boundary is: 1. **Inbound gate** (a network-connected "staging" host, not the deployment host): pull the artifact, record its hash, sign it with your organization's key, and store it in your **internal mirror**. 2. **Transfer** (one-way media for air-gap; verified internal network for IL2–IL6): carry the signed artifact to the deployment environment. 3. **Verify on load**: recompute the hash, verify the signature against your org key, and 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." The mirror is now your supply chain, and it is auditable. --- # 22.5 — Air-Gapped Deployment Design *Pre-load, sever, bind, log. The four verbs of air-gap.* 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. The design: 1. **Pre-load.** Every artifact the deployment will ever need — base weights, tokenizer config, system prompt, eval harness, dependency tree — is loaded onto the deployment host *before* the network is severed. This is the inbound-gate workflow from Step 5 above, with the addition that the gate is a physically separate machine. 2. **Sever the network.** 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. This is testable and should be tested continuously. 3. **Bind locally.** The inference server binds to `127.0.0.1` (loopback) or a Unix domain socket — never to `0.0.0.0`. The harness (the application consuming the model) 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. 4. **Log everything.** Audit logs are 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. ### Why llama.cpp and vLLM are the right substrate This is where the choices made in Module FT20 pay off. The two production-grade open inference stacks — **llama.cpp** (GGUF, CPU/Metal/CUDA, single-host) and **vLLM** (AWQ/FP8, CUDA, high-throughput) — share a property that matters enormously for air-gap: **minimal network posture**. - llama.cpp's `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 (Python, CUDA, dependency tree) but is still a single-process server with a defined OpenAI-compatible API surface. With a pinned mirror and a frozen `requirements.txt`, 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+; it is the only choice that satisfies the architecture. --- # 22.6 — The DoD Vendor Reality and the Open-Weights Response *The gap this curriculum exists to close.* In late 2024 and through 2025, the DoD's Chief Digital and Artificial Intelligence Office (CDAO) announced a slate of frontier-model partners for Nayvee-combatant-command use: **Anthropic, Google, OpenAI, and xAI**, among others. 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 (and the broader open-weights curriculum) exists to address: > **If every authorized government model is closed-weight, then every government model is unauditable at the weight level, and every IL5+/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 is: 1. **Open-data models are auditable in a way closed models structurally cannot be.** At IL5+ and on JWICS, that auditability is a deployment *requirement*, not a preference. 2. **The capability gap is closing.** Open frontier-class models (the Llama, Qwen, DeepSeek, and open-data families) are within striking distance of closed-weight capability on most operational tasks. The fine-tuning techniques in this course (Pillars 2–5) exist to close the residual gap on your specific task. 3. **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 2024 *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, in effect, the engineering-side reading of that report. --- ## Anti-Patterns ### Trusting community merges for classified work A merged community model (`Llama-X-OpenHermes-Smaug-vN`) whose provenance you cannot reconstruct, loaded into an IL5+ environment. This violates the re-derivability rule (22.2) 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. ### 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, and verify on load (Step 5). ### 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 0% of the adversarial surface. Promptfoo and Garak exist for a reason; run them every time, on every artifact, before any IL4+ load. (They are necessary, not sufficient — pair with Step 3 activation probing.) ### Assuming "open" means "safe" Open-weights is a *necessary* condition for auditability at IL5+; 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's open source" is not a security argument; it is the precondition for *making* a security argument. --- ## Key Terms | Term | Definition | | --- | --- | | **Impact Level (IL)** | DoD's categorization of information and systems by sensitivity, IL2 through IL7+. Determines FedRAMP baseline, allowed data class, and network. | | **FedRAMP** | Federal Risk and Authorization Management Program. Authorizes *cloud services* against control baselines (Low / Moderate ~325 controls / High). Does not certify model weights. | | **CUI** | Controlled Unclassified Information. Non-classified but sensitive (export-controlled, PII, law-enforcement). The dominant data class at IL4. | | **NIPRNet / SIPRNet / JWICS** | DoD networks: NIPRNet (unclassified), SIPRNet (SECRET), JWICS (TS/SCI, air-gapped). | | **Open-data model** | Weights **and** training corpus published (MiniCPM, OLMo, Tülu, SmolLM3). Auditable. Required at IL5+. | | **Open-weights-only** | Weights published, training data not (Llama 3.x). Trust the publisher's attestation. | | **Closed-weight** | Neither weights nor data. API-only. Incompatible with air-gap. | | **OWASP LLM03:2025** | Supply Chain Vulnerabilities — explicitly names LoRA adapter and model-merge compromise as a first-class vector. | | **MasqLoRA** | CVPR 2026 framework; first systematic LoRA supply-chain backdoor taxonomy. Survives quantization, merge, and weight-diff. | | **Diff-in-means probing** | Mechanistic-interp technique (FT17 abliteration, used defensively) that finds unexpected steering directions a backdoor would implant. | | **Inbound gate / pinned mirror** | The trust-boundary architecture: pull, sign, mirror, verify-on-load. Never `pull` inside the trust boundary. | | **NTIA (2024)** | U.S. government's *AI Open-Model Weights Report*; the policy citation for open-weights enabling sensitive-domain use. | --- ## Lab Exercise See `07-lab-spec.md`. "The Air-Gap Checklist" — a deployment-design lab (no GPU) producing a complete checklist for placing a fine-tuned model into an air-gapped IL5-equivalent environment: model provenance verification, quantization-reproducibility-from-source, network-severance verification, local-serving bind, and audit-logging spec. --- ## References 1. **Second Front Systems** — *DoD Impact Levels (IL2–IL6) Guide*. The practitioner-facing reference mapping ILs to FedRAMP baselines, data classes, and networks. 2. **StackArmor** — *FedRAMP and DoD SRG Impact Levels for Cloud*. The compliance-architect reference for IL overlays and authorized cloud postures. 3. **DISA / GSA** — *Cloud Computing Security Requirements Guide (CC SRG)*. The authoritative DoD source for IL definitions and cloud authorization. 4. **Microsoft** — *Microsoft Cloud for Government — Impact Levels*. Vendor documentation detailing IL2–IL6 support and the IL6 dedicated-cloud offering. 5. **OWASP** — *LLM03:2025 Supply Chain Vulnerabilities*. The Top-10 entry explicitly naming LoRA adapter and model-merge compromise. 6. **arXiv:2512.19297** — *Causal-Guided Detoxify Backdoor on LoRA Adapters*. Backdoor that appears benign on benchmarks. 7. **MasqLoRA (CVPR 2026)** — First systematic LoRA supply-chain backdoor framework. Survives quantization, merge, and weight-diff. 8. **OpenReview** — *"Down the Rabbit Hole of Backdoors."* Survey of compositional backdoor risk in the adapter/merge ecosystem. 9. **Anthropic (and related)** — *Small-samples-poison research.* A small number of poisoned samples can implant backdoors regardless of scale. 10. **PMC review** — *Clinical LLM deployment and LoRA's "double vulnerability" (data + adapter poisoning).* 11. **NTIA (2024)** — *AI Open-Model Weights Report.* The U.S. government policy citation for open-weights enabling sensitive-domain use. 12. **Module FT17** — *Abliteration.* The offensive use of diff-in-means; this module reuses the same toolkit defensively. 13. **Module FT20** — *vLLM and the Serving Stack.* The minimal-network-posture inference substrate this module's air-gap design depends on. 14. **Module FT21** — *HIPAA and BAA Elimination.* The open-data argument for healthcare; FT22 generalizes it to government.