The Ethics and Legality of AI Coding in Government Contracts

A government contractor's engineering team adopting an AI coding assistant is not making the same decision a commercial software company makes. The code being written may itself be regulated technical data. The repository it lives in may be subject to specific handling requirements written into the contract. And the question of who is legally accountable for a defect, or a leak, does not simplify just because a model helped write the line that caused it. Treating AI-assisted development on a government contract as a straightforward productivity upgrade, the way it might be treated at a consumer software startup, skips past a set of questions that a contracting officer, an inspector general, or opposing counsel in a dispute will not skip past.

None of this means AI-assisted coding is inappropriate for government work. It means the legality and the ethics of it turn on specifics: what data touched the model, what the contract says about that data, who can see what the tool produced and how. It isn't about the technology being generically fine or generically forbidden. Most of the genuine risk in this space comes from contractors reasoning about AI coding tools in the abstract instead of against their actual contract terms.

The data question is a contract question first

Every AI coding assistant does the same basic thing: it reads code and project context to generate suggestions, and in doing so it processes whatever is in that context. On a commercial project, what's in that context is the company's own intellectual property, and the company can decide for itself how much risk it wants to take with it. On a government contract, a meaningful share of that context (source code built to fulfill contract requirements, architecture documents, sometimes the technical data package itself) may be something the contractor does not have unilateral authority to disclose. Data rights clauses, technical data and computer software provisions, and program-specific handling requirements all constrain who else is allowed to see this material and under what conditions.

A cloud-hosted AI coding tool, whatever its terms of service promise, introduces a party into that chain who was not contemplated when those data rights were negotiated: the model vendor, and by extension whatever infrastructure and personnel sit behind that vendor's inference endpoint. Whether that constitutes an unauthorized disclosure is a specific legal question that depends on the contract's actual language, not a question this article can answer in general terms. But it is unambiguously the wrong kind of question to discover you should have asked after the fact, during a dispute or an audit. The prudent default for a contractor working with technical data of any sensitivity is to treat "does our AI tool's data flow match what our contract permits" as a question requiring an answer before the tool is adopted, not after.

Authorship, attestation, and who is accountable for the output

Government contracts frequently carry requirements around code provenance: attestations about where software components originated, certifications tied to secure development practices, and in some domains, explicit requirements about the composition of the development toolchain. AI-assisted generation complicates the paperwork trail those requirements assume, because "who wrote this function" no longer has a single clean human answer.

That complication is manageable, but it has to be managed deliberately rather than left implicit. A contractor's engineers remain the accountable party for code shipped under the contract regardless of what tooling assisted them. An AI suggestion that turns out to be a security defect is still the contractor's defect to own, and "the model suggested it" is not a posture that holds up in a dispute or a post-incident review. Some programs require disclosure of AI tool use in the development process as part of software bill-of-materials or provenance attestations; others don't yet address it explicitly, which is its own risk, since silence in a contract is not the same as permission. Contractors that get ahead of this treat AI assistance as a documented part of the development process, logged, attributable, reviewable, rather than as an invisible efficiency gain that nobody has to account for.

Where "the model learned from our code" becomes the real exposure

The sharpest version of the legal question isn't about a single prompt. It's about training and retention. A cloud AI vendor's terms may or may not permit use of submitted code to improve their models, may or may not retain prompts beyond the session, and may or may not be able to tell a customer, after the fact, exactly what was retained and where. For a contractor whose codebase touches controlled technical data, ITAR-relevant material, or information with export control implications, the possibility that fragments of that code persist somewhere in a vendor's training pipeline or logging infrastructure is not a theoretical concern. It's a question a government customer, an export control officer, or a security assessor is entitled to ask, and "we don't fully know" is not an answer that holds.

This is the point at which the ethical and legal questions converge on the same architectural answer. The ethical case for controlling where AI-assisted development happens isn't about AI being untrustworthy in some abstract sense. It's that a contractor accepting technical data under a government contract took on an obligation to control that data, and delegating part of the development process to infrastructure the contractor doesn't operate and can't fully audit is a way of quietly not fulfilling that obligation, even when nobody involved intends any harm.

What a defensible posture actually requires

Being able to answer these questions well doesn't require avoiding AI-assisted coding. It requires that the answers be structural rather than contractual — facts about what the system can do, not promises about what it won't do.

A development environment where the coding assistant runs entirely inside the contractor's own controlled facility, with no network path for source code or prompts to leave that boundary, answers the disclosure question without needing a favorable reading of a vendor's data-retention policy. It answers the training-exposure question the same way: code that never reaches a vendor's infrastructure cannot end up in a vendor's training data, regardless of what that vendor's terms say it does with submitted content. And because the environment is under the contractor's operational control, logging what was suggested, by what model version, in what session, becomes a design choice the contractor makes for itself rather than a request it has to make of an outside party who may or may not be able to fulfill it.

This is the specific problem Forge is built around — an air-gapped, sealed coding assistant appliance that runs inside a contractor's own facility, on Element 31's shared Substrate platform, with no path for source code or prompts to reach outside infrastructure. It doesn't resolve the underlying legal questions on its own; what counts as permitted disclosure under a specific contract's data rights clauses is still a determination for the contractor's counsel and contracting officer, not for a hardware vendor. What it does is remove the structural version of the risk, the one where the honest answer to "where did this code go" is a vendor's infrastructure nobody on the program can fully see into, and replace it with an architecture where that answer is, verifiably, nowhere but the facility the work was already authorized to happen in.