When the Agent Ships the Code: Ownership, Data Rights, and Liability for Autonomous AI in Federal Systems

For most of the software era, the legal questions around development tools were settled and dull. A tool suggested; a person decided, wrote, and owned the result. Responsibility ran to whoever sat at the keyboard.

Autonomous coding agents change that. A modern agent doesn't autocomplete a line. It reads a legacy codebase, plans an approach, writes and tests the change, and delivers finished work — sometimes opening the pull request itself. Point that capability at a federal or defense system and the old assumptions stop working. The tool is no longer suggesting; it is acting.

Once an agent acts inside a government environment, three unsettled questions land at once: who owns what it produced, what happens when that output is contaminated, and who answers for it when it breaks.

None of these questions is hypothetical, and none is covered by a standard commercial license. Solicitations and enterprise AI-use policies are already raising questions that off-the-shelf software clauses were never drafted to answer. What follows is a map of that contract terrain — for the companies deploying these agents, and for the program offices buying them.

Two Regimes, and You Need to Know Which One You're In

Before anything else: find out whether your customer is the Department of Defense.

FAR Subpart 27.4, Rights in Data and Copyrights, applies to every executive agency except DoD. A deal with a civilian agency runs on the FAR clauses — principally FAR 52.227-14, Rights in Data—General. A DoD deal runs on the DFARS clauses, principally DFARS 252.227-7014 for noncommercial computer software and DFARS 252.227-7013 for noncommercial technical data.

The two regimes use different vocabulary and reach different results. "Government purpose rights" is a DFARS concept; it does not appear in the FAR ladder at all. Vendors who learned data rights on a defense program and then sell to a civilian agency routinely argue from the wrong regulation.

There is a further wrinkle as of 2026. Under the Revolutionary FAR Overhaul, agencies have been issuing class deviations directing contracting officers to follow the FAR Council's model deviation text for Part 27 — and for the associated Part 52 clauses — in place of 48 CFR Part 27. Adoption is agency by agency, and effective dates vary. Before you argue a data-rights position, confirm which text your contracting officer is actually working from.

Ownership of Agent-Generated Code

In commercial work, ownership of AI-generated code is messy but low-stakes; the parties sort it out in the terms of service and move on. Federal contracting is different. Ownership there is a defined regime with real teeth, and it does not default to the vendor.

Everything turns on the first question, and it's the one vendors skip: is the software commercial or noncommercial?

Commercial computer software is acquired under FAR Part 12, and the government generally takes the license the vendor customarily offers the public. On the DoD side the corresponding treatment sits at DFARS 227.7202. Noncommercial software — developed for or delivered under the contract — is another world, governed by the data-rights clauses.

Many vendors assume "we're commercial, so our standard license governs" and stop reading. Autonomous generation is what makes that assumption dangerous, because it blurs whether a deliverable is the vendor's pre-existing product or something built under the contract.

The rights ladders. On the DoD side, rights run along a defined ladder: unlimited rights, government purpose rights, and — for software developed exclusively at private expense — restricted rights, with limited rights the analogue for privately developed technical data. On the civilian side, FAR 52.227-14 works differently: the government takes unlimited rights by default, and the contractor protects qualifying material by withholding it as limited rights data or restricted computer software and delivering form, fit, and function data instead.

That civilian default is harsher than most vendors expect. Under the FAR, the government acquires unlimited rights in data first produced in the performance of a contract, subject to the copyright provisions. Not a license. Unlimited rights — to use, disclose, reproduce, prepare derivative works, distribute to the public, and permit others to do the same.

Where the agent muddies the water. The model was trained by the vendor at private expense. But it ran on the government's data, inside the government's environment, and produced an artifact neither party's employee wrote. A vendor that assumes its proprietary-model output automatically carries restrictive markings can discover at delivery that the code is treated as first produced under the contract — with unlimited rights attaching on the civilian side, or government purpose rights on the defense side, to work it believed was its own.

Copyright isn't a workaround. Under the FAR clause, a contractor generally must obtain the contracting officer's permission before asserting copyright in a work containing data first produced in the performance of the contract. And where the contractor does assert copyright in computer software, the license running to the government covers reproduction, derivative works, public performance and display — everything except distribution to the public. Planning to assert copyright over agent output as a defensive measure is a plan that requires someone else's approval first.

The marking trap. Here is the provision that will catch a high-volume agent workflow. Data delivered under a contract containing the rights-in-data clause without a limited rights notice, without a restricted rights notice, and without a copyright notice is presumed to have been delivered with unlimited rights — and the government assumes no liability for disclosing, using, or reproducing it. There is a cure path: within six months, or longer for good cause, the contractor may ask the contracting officer for permission to add the omitted notices, but only by identifying the data, demonstrating the omission was inadvertent, establishing the notice is authorized, and accepting that the government bears no liability for anything already done.

Now picture an agent generating hundreds of files a week across a delivery. Marking discipline that was merely tedious when a human wrote every file becomes a systems problem. The rights you lose here, you lose by silence.

Model improvement. If the agent fine-tunes, caches, or retrieves against government data during performance, who owns the improvement? The vendor naturally wants to retain general improvements to the model. The government has little interest in allowing its data to enrich a commercial system it does not control. Answer that in the data-rights and IP clauses, expressly, before the first task runs.

Your Terms of Service Do Not Govern

Here is the rule most likely to surprise vendors — and, to be precise, the rule itself is not new. The FAR has said it since well before the overhaul. What the 2026 rewrite changed is everything that used to stand next to it.

For commercial computer software, the FAR prescribes no specific data-rights clause. Instead, the contract itself must specifically address the government's rights to use, disclose, modify, distribute, and reproduce the software. The regulation directs contracting officers to exercise caution in accepting a vendor's terms and conditions, on the ground that terms drafted for commercial sales may be inappropriate for government contracts, to address any inconsistencies in the contract — and states that the contract terms take precedence over the vendor's standard commercial agreement.

Read that against how autonomous coding tools are actually sold. The standard commercial terms assign output ownership to the customer, disclaim warranties, cap liability, and set retention and training terms. Vendors treat that document as the answer to the ownership question.

In a federal acquisition it is not the answer. It is an input the contracting officer is instructed to be careful with, and it loses to the contract where the two disagree. If the rights you need are only in your terms of service, and the contract is silent or says something different, you do not have them.

Now, what the overhaul removed. First, the policy section that had required agencies to balance the government's need for data against contractors' legitimate proprietary interests is reserved. Reasonable people will read that deletion differently — a plain-language cleanup, or a real loss of the argument a vendor used to make when a contracting officer reached too far. Either way, the argument is no longer sitting in the regulation waiting to be cited. Second, the pre-overhaul text pointed contracting officers to the Commercial Computer Software License clause at FAR 52.227-19 as a ready-made tool for reconciling a vendor's commercial agreement with the government's rights; the overhauled Part 27 text no longer references it. The precedence rule survived the rewrite. Its counterweights did not. What protects you now is the text you negotiated — and only that.

Provenance and the Open-Source Problem

Autonomous agents are trained on vast bodies of code, much of it open source under a range of licenses. In ordinary commercial development, an inadvertent snippet of copyleft code is a hygiene problem. In a government pipeline handling Controlled Unclassified Information, it's a compliance event.

Two risks compound. The first is license contamination: an agent can emit code derived from a strong-copyleft source, creating obligations no one chose and no one noticed until an audit or a downstream release surfaces them.

The second is provenance. Since Executive Order 14028, federal software has carried a concrete secure-development regime — the NIST Secure Software Development Framework (SP 800-218), the OMB self-attestation requirements (M-22-18, refined by M-23-16), and the CISA Secure Software Development Attestation Form, signed by a company officer. "An autonomous agent wrote it, and we're not fully certain what it drew on" does not survive that scrutiny. Worse, the attestation itself becomes False Claims Act exposure if it outruns what the vendor can support — the same trap that makes a CMMC affirmation dangerous. In a CUI environment, what the agent ingested, retained, and reproduced all become auditable facts.

The fix isn't to abandon the agent. It's to build license-scanning, provenance controls, and human-review checkpoints into the workflow, and to reflect those controls in the contract's representations. A vendor that can document how agent output is screened sits in a defensible position. A vendor relying on "the agent handles it" is underwriting a risk it never priced.

Liability When the Agent Is Wrong

This is the question that keeps general counsel awake. It's also the least settled of the three.

An autonomous agent introduces a defect into a federal system — a security vulnerability, a broken dependency, a subtly wrong implementation. Who's responsible? The vendor will point to human review and acceptance. The government will point to the vendor's representations about the tool. And current federal policy is clear that "the agent did it on its own" is not, by itself, a defense.

The closest-fitting guidance sits in DoD's Responsible AI program: the Department's AI Ethical Principles and its Responsible AI Strategy and Implementation Pathway, which put "responsible" and "traceable" at the center of how DoD fields AI. (DoD Directive 3000.09 gets cited here too, but it governs autonomy in weapon systems, not coding agents. Treat it as a signal of the Department's posture, not a rule on point.)

The trend is consistent: autonomy raises the need for a documented, accountable human. It never excuses the absence of one.

For a vendor, that means three contract disciplines, settled up front rather than discovered in a dispute:

• Allocation of responsibility — a negotiated line between the vendor's obligations for how the tool behaves and the government's obligations at review and acceptance. Don't let an unspoken assumption that acceptance washes the vendor's hands fill the gap.
• Indemnification scoped to autonomy — indemnity written for a world where the defect originates in an autonomous action. Get the direction right. Patent indemnity generally runs from contractor to government under FAR 52.227-3, while the authorization-and-consent clause at FAR 52.227-1, operating through 28 U.S.C. § 1498, can channel infringement liability to the government for work done on its behalf. So "IP indemnity" isn't one obligation; it's a question of which clause applies. Note also that the patent indemnity clause is not inserted when Part 12 procedures are used — so a vendor selling commercial software should not assume the clause is even in the contract. And the exposure that matters most for agent output — copyright and open-source license infringement — may fall outside a standard patent-indemnity clause entirely. Cover it expressly.
• A documented human-accountability record — the checkpoints, approvals, and audit trail that let both sides show a responsible human was in the loop. That's exactly what the emerging federal accountability posture will look for.

FedRAMP Authorization Answers a Different Question

A recurring assumption deserves direct treatment: that a FedRAMP authorization resolves the questions in this article. It does not, and the mismatch is structural rather than a gap someone forgot to close.

An authorization is a security determination about an environment. It says a cloud offering has been assessed against a control baseline and that an authorizing official accepted the residual risk. It makes no finding about who owns the code an agent produced inside that environment, whether that code carries open-source obligations, or who bears the loss when the agent ships a defect. Those are contract and intellectual-property questions, and they are resolved in the contract or not at all.

The distinction is worth holding onto because the standards work now underway may blur it in practice. NIST's Center for AI Standards and Innovation launched an AI Agent Standards Initiative in February 2026, and NIST's Control Overlays for Securing AI Systems project is developing SP 800-53 overlays for single-agent and multi-agent deployments. Related work at the National Cybersecurity Center of Excellence proposes treating agents as distinct non-human identities with their own authentication, authorization, auditing, and non-repudiation. Commentators have suggested those overlays could eventually inform FedRAMP requirements for AI systems. That remains speculative; as of this writing the agent overlays are in development without an announced publication date.

If it happens, it would be a genuine advance — and it would still not answer an ownership or liability question. Better security controls produce a better audit trail. An audit trail is evidence. Evidence is useful precisely because someone will eventually need to prove who did what. It does not decide who pays.

Why These Questions Belong in the Contract

All three problems come down to timing. Data rights left unspecified get supplied by default rules that rarely favor the vendor's assumptions — and on the civilian side, the default is unlimited rights in the government. Provenance controls not built in can't be attested to later. Liability not allocated up front gets allocated by a dispute, on someone else's terms.

The 2026 rewrite sharpens the point. With the balancing policy removed and the reconciliation clause no longer referenced, the rule that commercial terms yield to the contract now operates without its old counterweights — more of the outcome rides on language the parties actually negotiate and less on a regulatory backstop.

Autonomous agents compress the development timeline. That's their value. They do nothing to compress the legal exposure. The exposure does not wait for the retrospective.

I work this terrain as a Maryland attorney and a DCSA-certified Facility Security Officer and Insider Threat Program Senior Official — the certifications DCSA looks for when it inspects a cleared facility. That vantage sits on the seam where federal IP and data-rights law meets the security and contracting rules that govern classified and CUI performance. The companies best positioned to succeed selling autonomous capability into government won't be the ones with the best model alone. They'll be the ones who settled these answers in the contract before the first task ran.

Frequently Asked Questions

Who owns code that an AI agent generates under a federal contract?

It depends first on whether the customer is DoD, and second on whether the software is commercial or noncommercial. FAR Subpart 27.4 applies to every executive agency except DoD, so a civilian deal runs on FAR 52.227-14, where the government takes unlimited rights in data first produced in contract performance unless the contractor properly withholds and marks qualifying material. A DoD deal runs on DFARS 252.227-7014 for noncommercial computer software, where rights follow the unlimited / government purpose / restricted ladder. Commercial computer software is acquired under FAR Part 12, and on the defense side DFARS 227.7202, generally on the license the vendor offers the public. Autonomous generation blurs the commercial and noncommercial line and the private-expense test, because the output is produced by a vendor-trained model operating on government data inside a government environment. Absent express terms, a vendor can find broad government rights attaching to code it assumed was proprietary.

Does our standard terms of service settle the ownership question?

No, and this rule predates the 2026 overhaul. For commercial computer software the FAR prescribes no specific data-rights clause and instead requires the contract itself to address the government's rights to use, disclose, modify, distribute, and reproduce the software. It directs contracting officers to be cautious about vendor terms drafted for commercial sales, to address inconsistencies in the contract, and provides that the contract terms take precedence over the vendor's standard commercial agreement. The overhaul kept that rule while removing the balancing policy and the reference to the reconciliation clause at FAR 52.227-19 that stood alongside it. If the rights you rely on live only in your terms of service, and the contract says otherwise or says nothing, you should assume you do not have them.

What happens if we forget to mark agent-generated deliverables?

Under the FAR clause, data delivered without a limited rights notice, a restricted rights notice, or a copyright notice is presumed delivered with unlimited rights, and the government assumes no liability for disclosing, using, or reproducing it. A contractor may ask the contracting officer within six months — longer for good cause — for permission to add omitted notices, but must identify the data, show the omission was inadvertent, establish the notice is authorized, and accept that the government bears no liability for prior use. At the volume an autonomous agent produces, marking has to be an engineered step in the pipeline, not a habit.

What happens if an autonomous agent emits open-source-licensed code into a government deliverable?

It can create license-compatibility and provenance problems. Strong-copyleft-derived code can carry obligations incompatible with a proprietary or government deliverable, and federal expectations around software bills of materials and secure-development attestation make "we are not certain what the agent drew on" an untenable answer. The mitigation is license-scanning, provenance controls, and human-review checkpoints built into the workflow and reflected in the contract's representations.

If a human reviews and accepts the agent's work, is the vendor off the hook?

Not automatically. Human acceptance matters, but federal policy — including DoD's Responsible AI guidance — expects a documented accountable human and does not treat autonomy as a defense. (DoD Directive 3000.09 is often invoked here, but it governs autonomy in weapon systems, not coding agents.) Responsibility, indemnification, and the human-accountability record should be allocated expressly in the agreement rather than assumed to rest at acceptance.

Does a FedRAMP authorization cover any of this?

No. An authorization is a security determination about an environment measured against a control baseline. It makes no finding about ownership of agent-generated code, open-source obligations in that code, or liability for defects. Emerging NIST work on AI control overlays and agent identity may eventually shape security requirements for AI systems in federal environments, but better controls produce better evidence — they do not allocate rights or losses. That allocation happens in the contract.

Does the government get rights to improvements our model makes while performing the contract?

That has to be negotiated. If the agent fine-tunes, retrieves, or otherwise improves on government data during performance, ownership of that improvement is contested — the vendor wants the general-purpose gains, the government objects to its data enriching a commercial model. Address it directly in the data-rights and IP clauses before performance begins.

Is this different from ordinary AI-coding-tool procurement?

Yes. A tool that only suggests leaves development, ownership, and responsibility with the human. An agent that autonomously writes, tests, and ships shifts the analysis, because the artifact is generated by the tool and the federal data-rights, provenance, and accountability regimes all apply to that artifact. The contract terms that suffice for a suggestion engine do not cover an agent that acts.

Related reading: this is Part 1 of a two-part series — Part 2, Zero Data Retention Meets the Federal Record, covers what happens to the record of the agent working, and why a commercial retention term can cost you a federal deal. For the other federal compliance certification with False Claims Act teeth, see The CMMC Affirmation Trap. And for standing up a cleared company in the first place, see How to Start a Classified Contracting Company.