CMMC Level 2 is still assessed against the 110 requirements of NIST SP 800-171 Rev 2, which NIST withdrew on 14 May 2024, and 32 CFR 170.21(a)(2) bars AC.L2-3.1.20 External Connections and CA.L2-3.12.4 System Security Plan from ever appearing on a POA&M, so the coding assistant question has to be closed before assessment day rather than planned. The FedRAMP Marketplace listing FR1812058188 covers GitHub Enterprise Cloud under Tailored (LI-SaaS), certified 4 October 2018, and does not mention Copilot; GitHub said in October 2024 it would pursue Moderate, and its April 2026 changelog says Copilot will become FedRAMP authorized as part of GHEC-DR's authorization path, in the future tense. The Restrict Copilot to FedRAMP models policy buys FedRAMP Moderate model hosts and US data residency at a 10 percent increase in the model multiplier, is off by default, and does not authorize the Copilot service itself, which is what DFARS 252.204-7012(b)(2)(ii)(D) asks about. Content exclusion is not a boundary control: changes take up to 30 minutes to reach IDEs, and Copilot CLI and Agent mode in Copilot Chat do not support it at all. The posture that removes the vendor question entirely is inference that terminates inside the assessment boundary, where the assistant is simply another CUI Asset measured against the same 110 requirements. Start by pulling 30 days of egress logs and checking which developer subnets already reach the Copilot endpoints.
"Can we use GitHub Copilot with CUI under CMMC Level 2?" has no product-level answer. As of mid-August 2026 no primary GitHub source claims Copilot itself is FedRAMP authorized: the changelog of 13 April 2026 says Copilot "will become FedRAMP authorized as part of GHEC-DR's authorization path." Only the model hosts behind it are authorized today.
Scope follows the data, not the product. A C3PAO published guidance in July 2026 stating it in a line: if the assistant can access a document library containing CUI, it falls within scope. So the only defensible Copilot posture on a CUI boundary is the one where Copilot demonstrably never sees CUI, and buying the right plan settles none of it.
We ranked assistants on capability and cost in the enterprise AI coding agent buyer's guide; none of that changes this answer. What follows is what a Level 2 assessor accepts as evidence, and which requirements you cannot defer. Adjacent controls sit in the AI security pillar.
Four questions decide it, not the product name
What Level 2 actually demands of an external tool
32 CFR 170.14(c)(3) settles the baseline: "The security requirements in CMMC Level 2 are identical to the requirements in NIST SP 800-171 R2." Rev 2 was published in February 2020, updated on 28 January 2021, and withdrawn by NIST on 14 May 2024 in favour of Rev 3. Level 2 is still assessed against the withdrawn revision, so a gap analysis written against Rev 3 identifiers is written against the wrong document.
Five of the 110 do the work here.
32 CFR 170.21(a)(2) then removes the option of deferring. A Conditional Level 2 status needs all three of: a score divided by the total number of Level 2 requirements of at least 0.8, meaning 88 of 110; no POA&M item worth more than one point under the section 170.24 scoring methodology, the single carve-out being SC.L2-3.13.11 where encryption is employed but not FIPS-validated, scoring 3; and six requirements barred from a POA&M entirely, among them AC.L2-3.1.20 External Connections and CA.L2-3.12.4 System Security Plan.
Those two are the assistant question wearing a different label. A Conditional status also expires outright if the closeout assessment does not happen within 180 days of the Conditional CMMC Status Date.
| Requirement | NIST SP 800-171 Rev 2 text | What the assistant does to it |
|---|---|---|
| AC.L2-3.1.20 | "Verify and control/limit connections to and use of external systems." | Its discussion covers external systems used to process, store or transmit CUI, naming cloud services explicitly. |
| AC.L2-3.1.3 | "Control the flow of CUI in accordance with approved authorizations." | Prompt context is a flow. If the editor plugin picks what to attach, it authorizes the flow, not you. |
| CM.L2-3.4.9 | "Control and monitor user-installed software." | Extensions, CLI tools and MCP servers are user-installed software that reaches the network. |
| SC.L2-3.13.11 | "Employ FIPS-validated cryptography when used to protect the confidentiality of CUI." | Covers transport and anything cached on disk, a local index included. |
| CA.L2-3.12.4 | "Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems." | A connection absent from the SSP makes the SSP wrong. |
Where GitHub Copilot actually sits today
The FedRAMP Marketplace listing covering GitHub is FR1812058188: product GitHub Enterprise Cloud, certified 4 October 2018, Rev5, ongoing, 21 agency ATO and ATU letters. The authorization type is Tailored, which GitHub's own government FAQ describes as a baseline for "low risk Software as a Service (SaaS) systems." The listing does not mention Copilot. On 15 October 2024 GitHub announced it would pursue FedRAMP Moderate for that product, with no date attached.
The April 2026 changelog added data residency for the US and EU plus a policy restricting Copilot to models whose hosts hold FedRAMP Moderate authorization. That policy is named "Restrict Copilot to FedRAMP models", sits in the Features section of the enterprise Copilot policies, requires GitHub Enterprise Cloud with data residency in the US, is off by default, and adds a 10 percent increase in the model multiplier. Any Copilot extension or CLI version released in 2025 or later enforces it. The changelog names agent mode, inline suggestions, chat, the Copilot cloud agent, code review, pull request summaries and Copilot CLI among the covered features; Gemini is unsupported because Google Cloud does not currently offer data-resident inference endpoints. Cite the policy in your SSP, not a model list.
None of that addresses DFARS 252.204-7012 paragraph (b)(2)(ii)(D), which requires that "the Contractor shall require and ensure that the cloud service provider meets security requirements equivalent to those established by the Government for the Federal Risk and Authorization Management Program (FedRAMP) Moderate baseline." That clause points at the service handling the data. An authorization held by a model host is not an equivalency determination for the service that assembled the prompt, attached the repository context and returned the completion.
Microsoft 365 Copilot in GCC High is a different product with a different authorization boundary; its status does not transfer. GitHub publishes no GCC High or Azure Government Copilot offering, and its FedRAMP-models documentation mentions CUI, CMMC and ITAR nowhere. US data residency is also not sovereignty over the processing, a distinction worked through in data sovereignty and residency under the EU AI Act.
Three deployment shapes, compared
Shape A is not "non-compliant". It is unresolved, which is more expensive, because you produce the resolution rather than the vendor. The version that closes cleanly is the one where the assistant sits provably outside the CUI flow, and that is a network claim.
Shape B suits teams that want a frontier model and cannot self-host yet. AWS lists Anthropic Claude models on Amazon Bedrock as in scope for US GovCloud FedRAMP and DoD CC SRG IL4 and IL5, on a scope page last updated 28 July 2026: Claude 3.5 Sonnet and Claude 3 Haiku from May 2025, Claude 3.7 Sonnet from July 2025, Claude Sonnet 4.5 from November 2025. Confirm the service against its Marketplace listing the day you write the SSP entry.
| Dimension | A. Copilot on GHEC, US data residency | B. Agent or CLI on a government cloud endpoint | C. Inference inside the CUI enclave |
|---|---|---|---|
| Where inference terminates | A GitHub-operated service, FedRAMP Moderate model hosts, US region | A model endpoint in AWS GovCloud or equivalent, your own account | Hardware inside your assessment boundary |
| DFARS 7012(b)(2)(ii)(D) | Unresolved for the Copilot service itself | Satisfied by the provider's authorization for that service | Not triggered: no CSP handles the CUI |
| Asset category, 170.19 | CUI Asset if CUI can reach it; otherwise the burden of proof is yours | CUI Asset, cloud provider documented as an ESP | CUI Asset, assessed against all Level 2 requirements |
| AC.L2-3.1.20 answer | "We block it at the network and keep the logs", or nothing defensible | "Authorized, documented, limited to one endpoint" | "There is no external connection" |
| SC.L2-3.13.11 answer | The vendor's implementation, not yours to evidence | The provider's validated modules, cited by certificate | Yours to obtain and evidence, serving stack included |
| Who owns the CRM | GitHub, and no CUI-specific CRM is published | The cloud provider, per service | Nobody: no ESP relationship exists |
| Evidence that closes it | Egress denies plus logs proving CUI never left | Authorization letter, service description, CRM, data flow | Network diagram, inventory row, config baselines, logs |
| Realistic effort | Days of policy, weeks of network work | Weeks, mostly account structure and IAM | Weeks to months, plus permanent operational load |
Content exclusion is hygiene, not a boundary
Content exclusion is configured under Repository then Settings then Copilot, the same path in Organization settings, and Enterprise then AI controls then Copilot. The repository field is labelled "Paths to exclude in this repository".
# Repository -> Settings -> Copilot -> Content exclusion - "/src/some-dir/kernel.rs" - "secrets.json" - "secret*" - "*.cfg" - "/scripts/**"
The organization field is labelled "Repositories and paths to exclude" and keys lists by repository, with "*" applying everywhere.
# Organization -> Settings -> Copilot -> Content exclusion "*": - "**/.env" octo-repo: - "/src/some-dir/kernel.rs" https://github.com/primer/react.git: - "secrets.json"
Patterns use fnmatch notation and are case insensitive. A REST API manages the organization and enterprise lists.
The limits, from the same page. Changes take up to 30 minutes to reach IDEs. Exclusion is honoured by JetBrains IDEs, Visual Studio, Visual Studio Code and Vim/Neovim. And GitHub Copilot CLI and Agent mode in Copilot Chat in IDEs do not support content exclusion at all, which are exactly the two surfaces that read a whole working tree by design. Treat it as hygiene for keys and credentials files, never as a boundary.
The control that holds is egress. GitHub's Copilot allowlist reference, inverted, is the deny list for the CUI segment.
# Deny on the segment that holds CUI (GitHub's Copilot allowlist, inverted) https://github.com/login/* https://github.githubassets.com https://avatars.githubusercontent.com https://api.github.com/user https://github.com/copilot/* https://api.github.com/copilot_internal/* https://copilot-proxy.githubusercontent.com https://origin-tracker.githubusercontent.com https://*.githubcopilot.com/* https://*.individual.githubcopilot.com https://*.business.githubcopilot.com https://*.enterprise.githubcopilot.com https://collector.github.com/* https://copilot-telemetry.githubusercontent.com/telemetry https://default.exp-tas.com # with data residency, tenants also use: https://SUBDOMAIN.ghe.com https://*.SUBDOMAIN.ghe.com
Two details decide whether that list works. Routing is plan-specific: Copilot Business uses *.business.githubcopilot.com and Copilot Enterprise uses *.enterprise.githubcopilot.com, so a rule written against the wrong one silently permits the other. And GitHub documents that "if the proxy URL starts https://, the proxy is not currently supported", which breaks enclaves that terminate TLS at an inspecting proxy.
Three enterprise policies belong in the SSP explicitly. "Suggestions matching public code" is Blocked by default for Copilot Business users. "MCP servers in Copilot" must be enabled before MCP works at all, which makes it the place to stop an assistant acquiring new network reach. "Copilot coding agent" takes the values Enabled or No policy. Every new tool surface is another path out of the boundary, enumerated in the audit of agent data exfiltration channels.
Terminate the inference inside the enclave
Everything above argues about someone else's authorization boundary. Move inference onto hardware inside your assessment scope and the argument disappears. No CSP, so DFARS 252.204-7012(b)(2)(ii)(D) is not triggered. No ESP, so no service description and no CRM to negotiate. The assistant becomes a CUI Asset assessed against the same 110 requirements as the build server beside it, and AC.L2-3.1.20 is answered with a network diagram.
GitLab Duo Self-Hosted is the most direct version of this. It reached general availability in GitLab 17.9 and the Premium tier in 18.0; offline licences require the GitLab Duo Agent Platform Self-Hosted add-on. The documentation names vLLM, AWS Bedrock and Azure OpenAI among supported serving platforms, and states the property that matters for scoping: inference data, including code inputs, model prompts and model responses, does not leave the customer network. Only billing metadata leaves: instance ID, user ID, call count, timestamp.
Continue points an editor at any OpenAI-compatible endpoint with no vendor in the path. Its configuration lives at ~/.continue/config.yaml and requires the top-level keys name, version and schema. Model entries require name, provider and model, with apiBase, roles and capabilities among the optional keys. Allowed roles include chat, autocomplete, edit and apply.
# ~/.continue/config.yaml
name: cui-enclave-assistant
version: 1.0.0
schema: v1
models:
- name: Enclave Coder
provider: openai
apiBase: https://inference.enclave.internal:8000/v1
model: enclave-coder # the name registered at your endpoint
roles:
- chat
- edit
- apply
- autocompleteFor weights, an Apache-2.0 open-weight model keeps the licence question short. Qwen3-Coder-30B-A3B-Instruct has 30.5B total parameters with 3.3B activated, 128 experts of which 8 are active, and 262,144 tokens of native context. Its model card publishes no serving command, so take serving flags from your inference server's own documentation, and pre-stage the weights as in running vLLM air-gapped rather than letting a first run reach for a model hub. Weights pulled off a public hub are an untrusted import into the enclave, so vetting a model file when a clean picklescan report only means the blocklist matched nothing is the step that belongs between the download and the staging directory.
The GovCloud middle path is the one most often improvised. Claude Code against Amazon Bedrock is driven by environment variables, with credentials from the standard AWS chain (AWS_PROFILE, or AWS_ACCESS_KEY_ID with AWS_SECRET_ACCESS_KEY and AWS_SESSION_TOKEN, or AWS_BEARER_TOKEN_BEDROCK).
export CLAUDE_CODE_USE_BEDROCK=1 export AWS_REGION=<your GovCloud region> export AWS_PROFILE=cui-enclave # pin the models so the assessed config is the running one export ANTHROPIC_MODEL=us-gov.<model-id> export ANTHROPIC_DEFAULT_HAIKU_MODEL=us-gov.<model-id>
In AWS GovCloud regions Claude Code always uses the us-gov. prefix, the only one that routes within the GovCloud partition. The documented IAM policy grants four Bedrock actions: bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream, bedrock:ListInferenceProfiles and bedrock:GetInferenceProfile, plus aws-marketplace:ViewSubscriptions and aws-marketplace:Subscribe conditioned on "aws:CalledViaLast": "bedrock.amazonaws.com". Use it as the least-privilege baseline.
Self-hosting trades a vendor authorization problem for an operations problem. FIPS-validated cryptography for SC.L2-3.13.11 becomes yours to obtain and evidence, including for the serving endpoint and any on-disk cache, and patching, logging and model updates become a rota. The general comparison sits in cloud versus on-premise AI security and cost. The CMMC point is narrower: this is the shape where you control every artefact the assessor asks for.
What the assessor asks for, and what answers it
Three findings from the same C3PAO guidance belong in your readiness checklist. A SOC 2 report alone does not satisfy the FedRAMP Moderate equivalency requirement. Selecting a platform capable of handling CUI is a reasonable foundation, but the licence itself does not establish compliance. And a developer pasting CUI into a personal AI account is a spillage event regardless of who owns the device, which makes shadow usage an incident response problem; controls that catch that class of leak are in preventing data leakage in AI applications.
A vendor statement that prompts are never retained is an assertion, and assertions belong in the risk file, not the evidence package.
| The question | The artefact that answers it | What does not answer it |
|---|---|---|
| Where does code from this repository go? | Network diagram and data flow, with egress rules and 90 days of logs | A vendor privacy page or trust centre summary |
| Is the AI component in the SSP? | An entry naming the component, its boundary and its connections (CA.L2-3.12.4) | An SSP written before the tool was adopted |
| Which assets are in scope? | Inventory rows classified against the 170.19 categories, reconciled to the diagram | An inventory listing laptops but not what runs on them |
| Is the provider Moderate or equivalent? | An authorization package or equivalency body of evidence for that service | A SOC 2 Type 2 report, or an authorization held by a component underneath |
| Who is responsible for which control? | An ESP service description plus a customer responsibility matrix | An assumption that the vendor covers it |
| How is user-installed software controlled? | Extension allowlisting, device management evidence, policy settings (CM.L2-3.4.9) | An AI use policy that exists as a PDF |
| Is CUI protected with FIPS-validated crypto? | Module validation certificate numbers for the cryptography in the path | The answer "we use TLS 1.3" |
A decision path for this quarter
The CMMC acquisition rule, DFARS Case 2019-D041, was published in the Federal Register on 10 September 2025 as document 2025-17359 and took effect on 10 November 2025, starting Phase 1, which covers Level 1 and Level 2 self-assessments. Phase 2 begins one calendar year later, so Level 2 third-party assessment requirements start appearing in solicitations from 10 November 2026.
Inventory which repositories hold CUI. Not which projects are defence-related: which repositories contain export-controlled drawings, contract deliverables or technical data packages. The set is usually smaller than expected.
Decide whether CUI reaches a developer workstation. If it does, the workstation is a CUI Asset and every assistant on it is in scope, personal accounts included. If development happens in a hosted enclave, the question collapses to one boundary.
Pick a posture per repository class, not per company. Repositories holding CUI get shape B or C; the rest can run shape A under the rules for any other external service. One posture for the whole organization is either too expensive or not defensible.
Write the SSP entry before you buy anything. If you cannot draft the boundary, the connection and the asset category in three paragraphs, the architecture is not decided, and CA.L2-3.12.4 cannot go on a POA&M.
Treat AC.L2-3.1.20 as a gate. It is one of the six requirements barred from a POA&M, so the posture you pick has to close it on assessment day.
This week, pull 30 days of egress logs for every developer subnet and match them against GitHub's Copilot allowlist domains. If *.githubcopilot.com already appears from a segment holding CUI, you do not have a procurement question to schedule. You have a scoping finding to document and possibly a spillage report to file, both cheaper now than in front of an assessor.
FAQ
Quick answers to the questions this post tends to raise.
