AI Coding Agents in Federal and Defense Contracting Environments

Federal AI use is no longer a pilot program; it has become the job. The Department of Defense went from 254 AI contracts in 2022 to 1,319 in 2026, roughly a fivefold jump in four years, with that growth concentrated in production systems. OMB's 2025 Federal Agency AI Use Case Inventory counts 3,611 AI use cases across 41 reporting agencies, up from 2,133 the year before, with about half already deployed or in active pilot. That inventory does not even count the Department of Defense, so the real number across government is higher than what the public count shows.

The push has a name and a date behind it. On January 9, 2026, the Department of War issued three coordinated memoranda directing the department to become an "AI-first" warfighting force, organized around seven Pace-Setting Projects and backed by data-access mandates. Money followed fast. The Pentagon committed over $32 billion in contract ceiling to AI, cloud, and cybersecurity programs in the first half of FY2026 alone, including $200 million each to xAI, OpenAI, Google, and Anthropic for agentic AI systems meant to run in classified environments (Anthropic's contract was later terminated after a dispute with the Pentagon). This is a funded, dated, departmentwide mandate, and contractors building software for this market are already operating inside it.

What "agentic" means in this context

An AI coding agent does more than finish sentences faster. It reads codebases, writes and runs code, makes commits, and triggers other systems on its own, without someone approving each step. The Pentagon's $800 million in agentic AI contracts define the category this way: autonomous systems that interpret data, make decisions, and act inside classified environments without constant human direction.

The Enterprise Agents project says its goal is to transform enterprise workflows broadly, so it is not confined to weapons systems or intelligence platforms. It reaches into routine software development. The internal-use case, where a dev team adopts a coding agent to help build and ship software under an existing contract, is the one most contractors will run into first, and it is the focus here.

The compliance frameworks an AI coding agent must fit inside before a contractor can use it

No contractor gets to treat an AI coding agent as a gap in the rulebook. Every framework that already governs how controlled information is handled applies to the agent immediately, whether or not the people who wrote that framework had ever heard of a coding agent.

DFARS 252.204-7012 carries the most weight. Any AI tool that processes, stores, or transmits CUI sits inside the same security assessment boundary as every other system handling that data, and being "AI" buys no exemption. NIST SP 800-171 still governs any system touching CUI. Under CMMC 2.0, if you pick the wrong AI tool, findings can touch a contractor's entire certification, not just the tool itself. ITAR adds another layer: routing prompts or outputs for ITAR-controlled technical data through infrastructure outside the United States can amount to an unlicensed export, which is exactly the kind of thing international cloud-hosted AI tools can do without anyone intending it. Section 1532 of the FY2026 NDAA bars DoD contractors from using AI systems built by foreign adversary nations while they do DoD work, and that bar holds no matter where the model is hosted. GSA's new clause, GSAR 552.239-7001, takes effect October 19, 2026, and governs how contractors handle government data inside LLM-based AI systems sold to GSA; it adds a FedRAMP and CISA safe harbor for incident reporting and swaps out an older "unbiased AI principles" framework for a reasonable-efforts standard.

None of these rules were drafted with the others in mind. A single coding agent deployment can need to satisfy DFARS, NIST 800-171, CMMC Level 2, ITAR, FedRAMP authorization, the NDAA's foreign-AI prohibition, and the GSA data clause, all at once, all the time.

The CUI scoping gap that most System Security Plans get wrong

What actually gets a contractor in trouble is rarely the wrong tool; it is failing to write the right tool into the boundary. Most System Security Plans carefully document which humans can touch CUI, but they leave out the AI tools doing that same work. This gap appears during an assessment, at the worst possible moment to discover it.

Classified spaces make the problem unforgivingly concrete. A SCIF does not allow an outbound session to a hosted model, period. If a coding agent routes traffic to a cloud endpoint, it cannot be used in a SCIF under any documentation scheme anyone writes, no matter how thorough. Outside the SCIF, the gap is less binary, but it is no less real. The DoD CIO's "Accelerated Mission Software" guidance, signed August 31, 2026 and effective September 8, 2026, closes part of this gap by requiring DoD components and their industry partners to document every AI model, version, and dataset used, something like a Software Bill of Materials for AI. That requirement closes one hole and opens a new one: most contractors have not yet built the process to produce that documentation.

Contractor obligations under the DoD's "Accelerated Mission Software" guidance

Starting September 8, 2026, code written by an AI agent is no longer treated as equivalent to code written by a person, at least from a security standpoint. The guidance classifies it as "unverified input," a category that requires the same rigorous security testing as manually written code, no exceptions for how fast or how well the agent writes.

Signed by Kirsten Davies on August 31, 2026, the DoD CIO guidance sets a security and accountability baseline for every DoD and contractor software project that uses AI, and compliance was required immediately. The "unverified input" label is the key move: it treats AI-generated code the way a secure development lifecycle already treats a third-party library, as something that has to be tested, reviewed, and vouched for before anyone trusts it, regardless of who or what produced it. That posture has real evidence behind it. The 2026 GenAI Code Security Report found that roughly 44% of AI code generation tasks introduced a risky security vulnerability during testing, and the average security pass rate barely moved from the year before.

Two obligations follow directly. Projects must document every AI model, version, and dataset used, an equivalent of a bill-of-materials requirement, and that applies to any contractor using a coding agent in its development workflow, not just contractors building AI products for the DoD. And any contractor delivering code written with the help of an AI coding agent on a DoD contract needs a security testing workflow built specifically to cover that code, one it can actually demonstrate in documentation when asked. Both the pipeline and the audit trail it produces need to change to match.

Data rights law and AI coding agents

Data rights law under DFARS still governs AI coding agent output, but its core categories, "computer software" and "technical data," were built for a world of hand-written code and documents, not for model weights, embeddings, or output shaped by reinforcement learning from human feedback. The categories apply awkwardly to these things, and sometimes not.

That leaves open questions contractors have to answer before they sign, not after. If the fine-tuning used government-funded data, who owns the fine-tuned model weights? If an agent was trained on data the contractor considers proprietary, does the government get government purpose rights, unlimited rights, or limited rights to the code it generates? Is the agent itself "computer software" under DFARS? The final version, effective October 19, 2026, adds a carveout so IP assignment does not reach "general capability gains or generalized improvements that do not incorporate, derive from, reveal, or disclose Government Data," a real protection for contractors, though one that took direct negotiation to secure and that only applies on GSA vehicles. The earlier draft of that clause claimed ownership over all data outputs and runtime logs, and that was so commercially unworkable that it risked pushing the most capable AI companies away from GSA contracts. Contractors whose business depends on reusing models or training pipelines across multiple customers carry the sharpest exposure here: get the data rights wrong, and a contractor can end up having handed the government broad rights it never meant to give, or discover it legally cannot deliver what the contract requires.

False Claims Act exposure from AI coding agent use is active and expanding

Misrepresenting what an AI coding agent actually did, or billing commercial, off-the-shelf model use as if it were proprietary development, carries live exposure under the False Claims Act, and federal enforcement is already pursuing exactly this pattern.

A contractor that licenses a commercial foundation model, calls it "purpose-built" or "proprietary" in a proposal, and bills for development hours it never actually spent has stepped into FCA territory that DOJ has pursued under the Civil Cyber-Fraud Initiative, which in practice has focused on cybersecurity compliance misrepresentations in government contracts. The same enforcement logic extends naturally to AI claims. A contractor should give any AI-related language in a proposal the same scrutiny it would give cost or pricing data, because it is the same bar, not a lower one.

Vendor concentration risk and the model-agnostic requirement emerging in policy

Government policy is converging on a clear preference: multiple vendors, swappable models, no single point of failure. NSPM-11 states that past procurement approaches "fostered dangerous dependencies on single vendors," and it gives the Secretary of War, the Director of National Intelligence, and intelligence community agency heads 120 days to rework procurement processes around multi-vendor AI onboarding. The FY2026 NDAA adds teeth from a different direction, directing the DoD to build a cybersecurity framework for AI and ML technologies and fold it into DFARS and the CMMC program, covering supply chain risks like data poisoning, adversarial tampering, and unintentional data exposure across every AI tool in a contractor's stack.

For a contractor whose coding agent is locked to one commercial model, this is a structural problem, not an inconvenience. If that model gets suspended, ends up in a dispute, or falls under a foreign-AI prohibition like the one targeting DeepSeek, the contractor's entire development pipeline stops with it. The direction NSPM-11 points toward is architecture that can swap models without rebuilding the agent around them, running on infrastructure the contractor controls, with the operator choosing which model to run at any given time. Speed and flexibility, not loyalty to one vendor, is what procurement now rewards.

The operational posture that satisfies these requirements: what it looks like in practice

Every requirement covered so far points in the same direction. CUI boundary documentation, SCIF-compatible inference, bill-of-materials-style model logging, FCA-safe capability claims, and multi-vendor flexibility all converge on one architecture: a self-hosted, model-agnostic, auditable agent platform running inside the contractor's own authorization boundary.

If you self-host inside that boundary, you satisfy the SCIF no-network rule and DFARS 252.204-7012 without an extensive inherited-controls exercise. Inference runs on infrastructure the contractor already controls and has already had assessed. Model-agnostic design satisfies NSPM-11's multi-vendor push and protects the pipeline from single-model risk. Auditability closes the loop on the "Accelerated Mission Software" documentation requirement: the agent needs to produce a record of exactly which model, version, and dataset generated which output, kept as a compliance artifact that can be produced on demand, not treated as a reporting nicety. And because AI-generated code now carries the "unverified input" label, the platform needs real guardrails, review gates, and approval workflows built in, rather than letting the agent commit changes end to end without a human checkpoint.

This is not theoretical. The Army's agentic AI procurement automation work with Koniag Government Services won a 2026 ACT-IAC Innovation Impact Award for moving past the pilot stage into sustained, measurable value, and that shows this posture holds up in production. Because the codebase itself belongs to the contractor rather than a vendor, it can be extended to meet a specific agency's requirements without waiting on someone else's roadmap.

What contractors should do before the next solicitation

None of this is coming later. The compliance terrain for AI coding agents is already in force, and any contractor that has not reviewed its AI tool use against these requirements is already carrying risk it has not documented. Every AI tool touching CUI-adjacent data needs a check against the System Security Plan, because an undocumented tool doing CUI work is a finding waiting to be found in an assessment. SBOM-equivalent logging for AI-generated code needs to go in now, not later, since the September 8, 2026 DoD guidance already requires it, and that means tracking which model, version, and dataset produced which output and keeping that record as a compliance artifact. A real security testing gate needs to sit in front of AI-generated code, treating it as unverified input the same way a secure development lifecycle treats a third-party library, with the same SAST, DAST, and review steps applied before it ships. Legal review needs to look at data rights exposure before a new agent goes into production rather than after, flagging anywhere agent outputs, fine-tuned weights, or runtime logs could trigger a government rights claim under existing contract language. Every piece of proposal language touching AI capability needs the same scrutiny given to cost and pricing data, because claims about a coding agent's accuracy, autonomy, or proprietary nature are exactly where False Claims Act exposure tends to start. Check every model in the stack for its provenance against the NDAA's foreign-AI prohibition, because any model with Chinese development involvement is barred from DoD contract performance no matter where it is hosted.