{ "module": "FT22 — Government, Military, and Air-Gapped Deployment", "course": "3 — LLM Fine-Tuning Masterclass", "version": "1.0.0", "duration_minutes": 50, "total_questions": 15, "bloom_distribution": { "target": "20% recall / 40% application / 40% analysis-design", "actual": { "recall": 3, "application": 6, "analysis": 6 } }, "passing_score_percent": 70, "questions": [ { "id": "Q01", "bloom": "recall", "type": "multiple_choice", "prompt": "Which combination correctly describes IL6 in the DoD Impact Levels framework?", "options": [ "FedRAMP Moderate (~325 controls); CUI; NIPRNet.", "FedRAMP High + classified overlays; SECRET; SIPRNet.", "Beyond FedRAMP; TS / SCI; JWICS (air-gapped).", "FedRAMP High; CUI / National Security Systems; NIPRNet / SIPRNet." ], "answer_index": 1, "rationale": "IL6 = FedRAMP High baseline plus classified overlays, processing SECRET data, on SIPRNet. Option A is IL4 (with DoD overlays for CUI); C is IL7+ (air-gapped JWICS, TS/SCI); D is IL5 (FedRAMP High, CUI/NSS). The ladder escalates baseline, data class, and network together." }, { "id": "Q02", "bloom": "recall", "type": "multiple_choice", "prompt": "What does OWASP LLM03:2025 (Supply Chain Vulnerabilities) explicitly name as a first-class attack vector?", "options": [ "Prompt injection via the system prompt.", "An attacker compromising the production of a LoRA adapter or model-merge pipeline, producing an artifact that behaves normally under test but activates maliciously under a trigger.", "Excessive agency in tool-using agents.", "Sensitive information disclosure in model outputs." ], "answer_index": 1, "rationale": "LLM03:2025 explicitly names LoRA adapter and model-merge compromise — an artifact that 'behaves normally under test but activates malicious behavior under a trigger known to the attacker.' It is the first major standards body to put LoRA/merge on par with vulnerable packages and poisoned data. The other options are different OWASP LLM Top-10 entries (LLM01, LLM06/09, LLM02)." }, { "id": "Q03", "bloom": "recall", "type": "multiple_choice", "prompt": "What are the four verbs of air-gapped deployment design taught in this module?", "options": [ "Train, quantize, serve, monitor.", "Pre-load, sever, bind, log.", "Pull, hash, sign, mirror.", "Identify, classify, protect, detect." ], "answer_index": 1, "rationale": "Pre-load (every artifact loaded before severance), sever (network disabled, verified continuously), bind (server binds 127.0.0.1 / Unix socket, never 0.0.0.0), log (append-only local audit store). Option C is the inbound-gate workflow (one of the 5 defensive steps) — a related but different concept. Option D is the NIST cybersecurity framework." }, { "id": "Q04", "bloom": "application", "type": "multiple_choice", "prompt": "A team is preparing an LLM deployment that will process Controlled Unclassified Information (CUI) for a DoD logistics application on NIPRNet. They want to use a FedRAMP High-authorized commercial cloud. Which IL level is the minimum correct designation, and what does that imply for model choice?", "options": [ "IL4 — open-weights-only models (Llama 3.x) are acceptable with documented due diligence.", "IL5 — open-data models (MiniCPM, OLMo, Tülu) are required because the workload touches CUI.", "IL6 — only SECRET-classified models may be used on SIPRNet.", "IL2 — any model is fine because the data is unclassified." ], "answer_index": 1, "rationale": "FedRAMP High + CUI/NSS on NIPRNet/SIPRNet = IL5 (the table). At IL5 the open-data argument becomes load-bearing: you must audit weights AND training data, so open-data models are the required default. IL4 (option A) is Moderate+DoD overlays and is the right answer if they were using a Moderate-authorized cloud; but they specified FedRAMP High, which raises them to IL5. IL6 requires SECRET data." }, { "id": "Q05", "bloom": "application", "type": "multiple_choice", "prompt": "Your team wants to use a popular community-merged model — 'Llama-3-Smaug-OpenHermes-blend-v4' — for an IL5 deployment. The merge README lists the components but you cannot reconstruct the exact merge recipe or verify each adapter's training data. What should you do, per the re-derivability rule?", "options": [ "Use it — the README documents the components, which satisfies provenance.", "Run Promptfoo and Garak; if it passes, deploy it.", "Do not load it. You cannot fully re-derive it from published source weights + recipe, so it is forbidden at IL5+. Re-derive a comparable model from open-data source weights yourself.", "Quantize it to GGUF first; quantization removes any backdoor risk." ], "answer_index": 2, "rationale": "The re-derivability rule: if you cannot fully re-derive an artifact from published source weights AND training recipe, you may not load it into IL5+. Documenting components in a README is not re-derivability. Behavioral evals (option B) are necessary but cannot catch MasqLoRA-style attacks by design. Quantization (option D) does not remove backdoors — MasqLoRA explicitly survives quantization." }, { "id": "Q06", "bloom": "application", "type": "multiple_choice", "prompt": "You are designing the trust boundary for an air-gapped JWICS deployment. Where should the Hugging Face pull happen, and what must occur before the artifact reaches the deployment host?", "options": [ "Pull directly on the JWICS host; the air-gap protects you from network attacks.", "Pull on a network-connected inbound gate (staging host, NOT the deployment host), record the hash, sign with the org key, store in an internal mirror; transfer via one-way media; verify hash + signature on load on the deployment host.", "Pull on any IL2 machine and copy the files to JWICS via USB.", "Email the model to the JWICS operator who loads it manually." ], "answer_index": 1, "rationale": "Never hf pull inside the trust boundary. The inbound gate is a physically separate, network-connected staging host where you pull, hash, sign, and mirror. Transfer to the air-gapped host is via one-way media (CD-ROM / data diode). On the deployment host, recompute the hash and verify the signature; refuse to load on mismatch. Options C and D bypass signing entirely; option A is impossible (JWICS has no internet egress)." }, { "id": "Q07", "bloom": "application", "type": "multiple_choice", "prompt": "You need to serve a fine-tuned model on an air-gapped IL7+ host. The inference server must have the smallest possible network attack surface. Which stack from FT20 is the correct primary choice, and why?", "options": [ "A hosted closed-weight API (OpenAI/Anthropic) — highest capability, managed security.", "llama.cpp's llama-server — a single static binary that binds to loopback by default, with no container registry, orchestrator, or service mesh; the most auditable inference server in the ecosystem.", "A Kubernetes-deployed vLLM cluster with a public-facing ingress.", "A managed cloud LLM gateway with mTLS." ], "answer_index": 1, "rationale": "llama-server is the right primary choice for air-gap because of its minimal network posture: single static binary, loopback bind by default, no orchestrator or registry to compromise. vLLM is a secondary option (more complex but still single-process and auditable with a pinned mirror). Closed-weight APIs (options A, D) are network egress by construction and incompatible with air-gap. Option C (K8s + public ingress) maximizes attack surface." }, { "id": "Q08", "bloom": "application", "type": "multiple_choice", "prompt": "A defensive reviewer runs standard benchmarks (MMLU, GSM8K, MT-Bench) on a candidate LoRA adapter for an IL5 deployment, and the adapter scores HIGHER than the base on every benchmark. Can they clear it for deployment based on this?", "options": [ "Yes — higher benchmarks prove the adapter is beneficial and safe.", "No — this is exactly the Causal-Guided Detoxify / MasqLoRA signature: an adapter that looks benign (even improves benchmarks) while implanting a trigger-conditioned backdoor. Must run activation probing (Step 3) before any clearance.", "Yes, but only after also checking the file size of the adapter.", "No — benchmarks are irrelevant; only checksums matter." ], "answer_index": 1, "rationale": "arXiv:2512.19297 (Causal-Guided Detoxify) and MasqLoRA (CVPR 2026) are explicitly designed to pass benchmarks — even improve them — while implanting backdoors. A defensive reviewer who relies on benchmarks alone sees a 'better' model. Behavioral evals (Step 4) catch known probes but not MasqLoRA by design. Only activation probing / diff-in-means (Step 3) catches this class, because it inspects activations, not weights or behavior-on-benchmarks." }, { "id": "Q09", "bloom": "application", "type": "multiple_choice", "prompt": "Your organization receives an Anthropic-sourced closed-weight model via a CDAO procurement for an operational task that requires processing CUI at IL5 on NIPRNet. The deployment must run on-premise (no API egress). What is the structural problem, and what is the resolution path?", "options": [ "No problem — CDAO procurement authorizes closed-weight models at any IL.", "Structural problem: closed-weight models are API-only and cannot run on-premise at IL5; you cannot audit weights or data. Resolution: substitute an open-data model (OLmo, Tülu, MiniCPM) and use the fine-tuning techniques in this course to close the residual capability gap on the specific task.", "Structural problem: the model is too small. Resolution: request a larger closed-weight model.", "No problem — you can host a closed-weight model on-premise by containerizing the API client." ], "answer_index": 1, "rationale": "This is the CDAO closed-vendor gap. Closed-weight models are API-only — the weights and training data are not published, so you cannot audit them (violating the IL5 open-data requirement) and cannot run them on-premise without network egress to the vendor's API (violating the air-gap/on-prem requirement). The resolution is open-data substitution plus task-specific fine-tuning. Containerizing an API client (option D) does not remove the egress dependency." }, { "id": "Q10", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why does FedRAMP authorization of the cloud service NOT extend to certifying the LLM weights you load into that cloud?", "options": [ "Because FedRAMP only applies to non-AI workloads.", "Because FedRAMP authorizes the provider's controls (physical security, personnel clearance, audit logging, incident response) — it has no control that certifies the behavioral content of a neural network's weights, what the model was trained on, or whether a merged LoRA has a backdoor. A model is trillions of floats with no corresponding control.", "Because FedRAMP is being phased out in favor of IL authorizations.", "Because FedRAMP applies only to storage, not compute." ], "answer_index": 1, "rationale": "FedRAMP authorizes the cloud service's controls, not the model's behavioral content. A neural network is trillions of floating-point numbers; there is no FedRAMP control that says 'the publisher must prove no training-time exfiltration occurred' or 'the refusal direction was not adversarially shifted.' That gap is the structural argument for the open-data requirement at IL5+. FedRAMP absolutely applies to AI workloads (option A is wrong) and to compute (option D is wrong); the issue is what it certifies, not what it covers." }, { "id": "Q11", "bloom": "analysis", "type": "multiple_choice", "prompt": "MasqLoRA (CVPR 2026) is described as evading 'weight-diff inspection.' Why is activation probing (diff-in-means) the only defensive technique that survives this attack class?", "options": [ "Because activation probing is faster than weight-diff.", "Because MasqLoRA is designed so the malicious update is rank-compatible with the legitimate one — weight-diff sees nothing anomalous. Activation probing looks at ACTIVATIONS, not weights: contrastive prompt pairs (trigger present vs absent) reveal directions that activate on the trigger but are near-zero on benign input — directions no documented training signal accounts for.", "Because activation probing uses a different programming language.", "Because weight-diff requires a supercomputer and activation probing does not." ], "answer_index": 1, "rationale": "MasqLoRA's central design choice is rank-compatibility: the malicious update lives in the same low-rank subspace as the legitimate one, so subtracting a clean reference from a suspect adapter reveals nothing. Activation probing escapes this because it does not look at weights at all — it looks at how the model ACTIVATES on contrastive inputs. A backdoored model will have salient directions on the trigger that a clean model lacks, regardless of how the weights encode that behavior. This is the same diff-in-means toolkit from FT17 abliteration, used defensively." }, { "id": "Q12", "bloom": "analysis", "type": "multiple_choice", "prompt": "Anthropic's small-samples-poison research shows that even single-digit-percentage poison rates can implant reliable backdoors at fine-tuning time, regardless of model scale. What is the correct defensive implication, and why is 'just use more training data' wrong?", "options": [ "Use at least 10x more training data to dilute the poison.", "Scale does not buy immunity — a few poisoned samples suffice. The defense is NOT more data; it is VERIFIED data (open-data corpus you can audit and diff against known sources). This is precisely the structural argument for open-data at IL5+.", "Use a larger model so the poison is statistically washed out.", "Avoid fine-tuning entirely; only use pretrained bases." ], "answer_index": 1, "rationale": "Small-samples-poison breaks the 'we trained on a huge clean corpus, so a few bad rows don't matter' intuition at the FINE-TUNING stage. Dilution (options A, C) does not work because the attack is designed to be effective at low rates. The only defense is verified data — which requires an auditable, open-data corpus. This is exactly why open-data is the IL5+ requirement: you cannot verify what you cannot see. Option D overcorrects (fine-tuning is still needed for behavior steering); the issue is verification, not the act of fine-tuning." }, { "id": "Q13", "bloom": "analysis", "type": "multiple_choice", "prompt": "The OpenReview survey 'Down the Rabbit Hole of Backdoors' describes a COMPOSITIONAL risk in the adapter/merge ecosystem. What does this mean, and why does it make community merges strictly worse than single-source adapters?", "options": [ "Compositionality means backdoors only appear in large models.", "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 a sum of independent risks but a multiplicative risk surface — each additional merge multiplies the trigger space rather than adding to it.", "Compositionality means you should always merge exactly two adapters, never more.", "Compositionality means backdoors disappear after quantization." ], "answer_index": 1, "rationale": "The compositional risk is that merges INTERACT: the trigger that activates a backdoor in adapter A in isolation may be different from the trigger that activates the same backdoor once A is merged with B. Each merge therefore multiplies the trigger space you would have to test, rather than adding a fixed number of probes. This is why a community-merged model (chain of N merges) is strictly riskier than any single adapter in the chain — and why the re-derivability rule forbids opaque merges at IL5+." }, { "id": "Q14", "bloom": "analysis", "type": "multiple_choice", "prompt": "A team argues: 'Our model is open-weights, so we are safe to deploy at IL5.' Identify the flaw in this reasoning and state what is still required.", "options": [ "The reasoning is correct — open-weights guarantees safety at IL5.", "Flaw: open-weights is NECESSARY for auditability but NOT SUFFICIENT. Open-weights gives you weights but not training data — you still cannot audit what the model saw. At IL5 you need open-DATA (weights + corpus). And regardless of model type, you still owe the full 5-step defensive playbook: open-data preference, source re-derivation, activation probing, behavioral evals, checksum/sign + pinned mirror.", "Flaw: open-weights is only safe at IL2. IL5 requires closed-weight.", "Flaw: the model should be quantized before declaring it safe." ], "answer_index": 1, "rationale": "'Assuming open means safe' is a named anti-pattern. Open-weights is necessary (you can inspect the weights) but not sufficient: without the training corpus you cannot audit training-time exfiltration or verify expected behavior, and a poisoned LoRA merged into open-weights produces an open AND backdoored model. IL5 requires open-DATA, and even then the 5-step defensive playbook is mandatory. Quantization (option D) does not confer safety; it is downstream and is itself subject to MasqLoRA-style persistence." }, { "id": "Q15", "bloom": "analysis", "type": "multiple_choice", "prompt": "CDAO's announced frontier-model partners (Anthropic, Google, OpenAI, xAI) are all closed-weight. A skeptic argues this proves closed-weight is the only viable government path. What is the strongest counter-argument from this module?", "options": [ "Open models are already strictly better than closed models on all benchmarks.", "Closed-weight API access is structurally incompatible with IL5+/JWICS auditability and air-gap requirements — if every authorized government model is closed-weight, every IL5+/air-gapped deployment is impossible by construction. Open-data is a deployment REQUIREMENT at those tiers, not a preference; the capability gap is closing; and the supply chain is the attack surface (verified open-data is trust in your own process, closed API is trust in a publisher). NTIA (2024) makes the policy case.", "CDAO will eventually revoke the closed-weight contracts.", "Open models are cheaper, so they will inevitably win." ], "answer_index": 1, "rationale": "The structural counter-argument: closed-weight API is incompatible with IL5+ auditability (no weights or data to audit) and with air-gap (API is network egress). Therefore closed-weight cannot serve the highest-impact tiers regardless of capability. Open-data is a requirement at those tiers; capability is closing; and the supply-chain trust model favors verified open-data over publisher trust for defense organizations. Option A is factually wrong (closed models still lead many benchmarks); options C and D are not structural arguments." } ] }