Copyleft Liability When an AI Coding Agent Commits Autonomously

How copyleft obligations arise

Copyleft licences condition reuse on how the resulting work is shared. The GNU GPL is the canonical example: it requires derivative works to be licensed under the GPL as well. Some open source licences also require that anyone who releases a modified program releases its source code alongside it. Permissive licences carry no clause that extends the licence to derivative works, which is why the distinction matters when code of unknown origin enters a proprietary codebase.

The obligations differ between licence versions, and AGPL-3.0 is generally understood to extend its conditions to network use as well as distribution. Counsel should confirm the exact triggers against the licence texts in play.

In general terms, the obligation does not arise because a commit exists. It arises when the organisation releases or makes use of the resulting software in a way the licence addresses. That is why an autonomous commit is a risk event even though the legal consequence comes later. The code is already in version history, may be built into a release, and carries no recorded origin or licence context to tell anyone it needs attention. This is general explanation, not legal advice.

How liability is generally allocated, and what is unsettled

Three parties are involved: the tool vendor, the organisation deploying the tool, and the developer who enabled autonomous commits. Vendor terms typically address who owns generated output, whether any indemnity applies, and what the customer must do to stay compliant. Indemnities are often scoped, and exclusions may matter most for exactly the autonomous use this guide covers. NIST AI 600-1 notes that vendor services and non-standard terms can amplify or defer liability in unexpected ways, and suggests a clear assignment of liability and responsibility for incidents.

Whatever the contract says, the organisation that distributes or operates the software is the party facing the licence holder. A vendor indemnity, where one exists, is a route to recovery. It does not remove the organisation's own obligations. Internally, responsibility sits with whoever set the policy that allowed autonomous commits, not only with the developer who switched the feature on.

The wider legal position is unsettled. The Copyright Office asked in 2023 how liability should be apportioned between the user whose instructions prompted an output and the developers of the system and dataset when an output is substantially similar to a work that does not qualify as fair use. The FTC raised the same apportionment question among users, tool developers and dataset developers. Those were posed questions, not rules. Until the law settles, contract allocation and internal policy are the main practical levers.

Enforcement in the execution path versus review after the fact

Review after the fact is a weak control for autonomous commits. By the time a reviewer or scanner sees the change, it is in history and may already have shipped. Remediation then means rewriting history, replacing code and assessing what was released.

The alternative is to enforce policy at the point where the agent acts, at commit time and at tool-call time, so a change that violates policy is stopped, redacted or routed to a human before it is written. This is an architectural distinction rather than a product claim. A check in the execution path acts before the code exists in the repository. A check after merge acts on a fact already established.

The pattern has precedent in supply chain practice. NIST SP 800-204D recommends that a security team establish a policy for trusted sources of open source software, such as allow lists, covering coding requirements, reputational standards and signed source packages. The same idea applies to agent output: define acceptable origins and licences as policy that tooling can check, instead of relying on each developer's judgement. The control is only as good as the decision it applies, so the organisation must also decide which repositories or change types permit autonomous commits and which require human approval.

Provenance and evidence an auditor can use

Two records matter. The first is code provenance: for each agent-generated change, the origin, the licence context and the security context of the code. Without it, a later licence question cannot be answered from the repository, because the commit looks like any other.

The second is a record of agent behaviour: what the agent was permitted to do under policy and what it actually did. This follows from the third-party risk guidance for banking organisations, which expects ongoing monitoring commensurate with risk, including reviewing reports on a third party's controls and regularly testing your own controls over third-party risks. Testing a control requires evidence that it operated. Retention length and storage location should be set deliberately, since the evidence may be needed long after the code was written.

A register of the AI coding agents in use also helps. The Stop Rogue AI Act bill, H.R.10362, would direct NIST standards toward discovery, inventory, verification and organisational control of AI agents, applied consistently to internally built, vendor-supplied and externally run agents. As of November 2026 it is a bill, not law, and it does not address licensing. Its inventory framing is still a sound operating practice.

Where Trussed applies

Trussed enforces policy in the execution path across coding assistants, agents, tools and MCP servers. Enforcement actions are allow, redact, block, rate limit and escalate for human approval, applied to individual interactions and tool calls. Code provenance supplies the origin, licence and security context of code, so policy decisions and later review have that context available. Enforcement produces audit-ready evidence, with self-managed deployment in the customer cloud and configurable retention and data residency.

The scope is specific. Trussed applies to individual interactions and tool calls. It is not a substitute for contract review or legal analysis of licence obligations, and it does not provide end-to-end tracing of agentic workflows.