When the Fiscal Year 2026 National Defense Authorization Act became law, the AI provisions that drew the headlines were the ones about which models the Pentagon is allowed to buy. But buried in Title XV — the cybersecurity title — is the one provision in the entire NDAA AI package that names the exact failure mode most security teams are losing sleep over. Section 1512 directs the Department to govern data leakage. And it set a deadline that is now less than three months away.
That detail matters because "data leakage" is not a procurement problem. You cannot buy your way out of it by clearing a model through an oversight board. It happens at the moment a cleared person decides what to type — and that moment lives at a layer no acquisition framework was written to reach.
Section 1512, in its own words
Here is what the provision actually requires, per Akin Gump's summary of the compromise defense bill:
Within 180 days of enactment, the provision directs DoD to establish a Department-wide cybersecurity and governance policy for AI and machine learning (ML), addressing lifecycle security, industry standards, workforce training and protections against AI-specific threats such as model tampering and data leakage. The Department must then conduct a comprehensive review of its AI/ML cybersecurity practices and report the findings to Congress by August 31, 2026.
Crowell & Moring's client alert fills in the procedural frame: the FY 2026 NDAA (P.L. 119-60) was signed into law on December 18, 2025, and the Section 1512 report to Congress has to carry "an assessment of current practices, identified security gaps, and recommended enhancements." Congress also clarified, in the Joint Explanatory Statement, that the Department's software bill of materials (SBOM) policies should apply, "where feasible," to AI systems used, developed, or acquired by DoD.
Two things stand out. First, Section 1512 is a governance and cybersecurity mandate, not a procurement filter — it is about how the Department secures and oversees the AI it uses, not only the AI it buys. Second, it is the only AI provision in the bill that calls out data leakage by name. Its neighbors govern adjacent surfaces: Section 1533 stands up the CDAO-led model-assessment team, Section 1513 builds a procurement-security framework on the NIST SP 800 series and the Cybersecurity Maturity Model Certification (CMMC) program, and Section 1532 bans AI from DeepSeek and High Flyer outright. Section 1512 is the one left holding the question those others sidestep: how does the data actually leak, and what stops it in real time?
Where defense AI data actually leaks
Ask where a controlled-unclassified-information (CUI) leak into an AI system originates inside a cleared organization, and the honest answer is almost never "the model we procured." It's the consumer chatbot a cleared engineer has open in a browser tab while they're heads-down on a covered program. Claude, ChatGPT, Gemini, Copilot, Grok, Perplexity — none of these clear any acquisition framework, because nobody acquired them. Someone typed the URL into a tab and pasted in a paragraph about a controlled assembly to "clean up the wording."
That is the data-leakage event Section 1512 is pointing at. It is a workforce-behavior problem expressed through a browser, and it sits entirely on the deployer — the DoD component, the prime, the aerospace OEM, the FFRDC running commercial AI for its people. The Department can ban a foreign model under Section 1532 and assess a domestic one under Section 1533, and a cleared employee can still drop export-controlled text into a perfectly approved commercial assistant. The model's pedigree was never the variable. The data movement was.
What an August 31 self-assessment has to be able to show
The near-term forcing function in Section 1512 isn't the policy itself — it's the comprehensive review the Department owes Congress by August 31, 2026, with its "assessment of current practices" and "identified security gaps." Any honest data-leakage self-assessment has to answer a question that procurement records cannot:
When a cleared user moved program data into an AI model that no contract ever touched, what control governed that flow, and where is the evidence?
If the answer is "acceptable-use policy and an annual training slide," that is the gap the review is designed to surface. A defensible answer needs a runtime control that sees the prompt before it leaves the workstation, evaluates it against the organization's policy, and produces an audit record of the decision. That is a different class of evidence than "we bought a model that passed the Section 1533 framework" — and it is exactly the kind of gap an August 31 self-assessment is supposed to flag rather than paper over.
Two layers, one report
The clean way to read the NDAA's AI title is as two separable layers. Sections 1513, 1532, and 1533 govern the supply side — which models are allowed, how they're assessed, what cybersecurity baseline applies. Section 1512's data-leakage mandate forces attention onto the data-boundary side — what content is allowed to cross from a cleared workstation into any LLM at all, procured or commercial, sanctioned or shadow. The first layer is about the model. The second is about the keystroke. Congress, in naming data leakage, put both on the same report.
That second layer is what Containment.AI's browser extension and policy proxy are designed to enforce: inspect the prompt at the point of egress, evaluate it against the customer's configured policy — CUI markings, NIST SP 800-171 control families, internal CDI tags — and allow, redact, or block the data movement in real time, with an audit trail of every decision. We make no FedRAMP, IL5, or CMMC authorization claim; the product is a real-time data-boundary control, and its job is to give a security team the runtime evidence a Section 1512 review actually asks for. It does not replace the model-assessment work — it answers the question that work leaves open.
The deadline that's already here
If your organization will sit on either side of a Section 1512 data-leakage review in the next year, three steps before August 31:
- Separate your supply-side and data-boundary AI controls in writing. "We govern which models we field" and "we govern what cleared users paste into any model" are two programs with different owners, different tooling, and different audit evidence. A review that conflates them will read as a gap.
- Inventory your commercial-LLM browser surface across cleared programs. For every program with CUI exposure, count how many cleared users have browsers logged into consumer AI surfaces. In the deployments we see, that number is consistently larger than the program office's estimate — and it is the precise population a data-leakage policy has to cover.
- Match your evidence to the question, not the framework. The examiner — and the August 31 report — cares about where the data crossed, not which board the model cleared on its way in. Make sure you can produce a per-event record at that boundary.
Congress gave the Pentagon a clean deadline to tell it how AI data leakage is governed. The honest version of that report has a line item for the browser tab — because that is where the leak starts, and no model-assessment framework was ever pointed at it.