AGPL Code Liability When AI Coding Agents Pull Code into Production

How AGPL obligations can attach to agent-introduced code

The GNU Affero General Public License v3 is a copyleft licence. Its distinguishing feature is section 13, which addresses users who interact with modified software remotely over a network. For a company that runs software as a service, that means the usual assumption that internal or hosted use creates no distribution duty does not hold for AGPL code. Whether a source-offer obligation applies depends on facts that legal teams must assess, including how the code is used, whether it has been modified and how users interact with the system.

An agentic coding assistant changes how the code arrives, not what the licence says. The agent may retrieve a snippet, generate code that closely resembles licensed material, or add a package whose licence is AGPL-3.0. If a developer accepts the change without reading the licence, the obligation is not removed. It is simply unnoticed.

This is why the problem is one of enterprise control. The enterprise deploys the system, so the enterprise is the party most exposed when the code is running in production. NIST's AI RMF 1.0 states that all parties and AI actors should manage risk in the AI systems they develop, deploy or use. Treating AGPL exposure as the vendor's problem does not fit that expectation.

Where liability sits, and what is still open

Four parties are involved. The enterprise operates the production system and carries the practical consequence of any licence obligation. The developer accepted the agent's output and is the person whose review step the organisation relied on. The tool vendor supplies the agent and typically limits its liability in its terms. Upstream licensors hold the rights in the original code and set the conditions for its use.

What can be said with confidence is limited. NIST's Generative AI Profile lists the unauthorised reproduction of licensed content as an intellectual property risk. It also warns that vendor services with non-standard terms may amplify or defer liability in unexpected ways, and it advises a clear assignment of liability and responsibility for incidents. It does not map these points to AGPL or to coding agents.

The apportionment between the person who prompts a system and the developer of the system is genuinely open. In 2023 the U.S. Copyright Office asked how liability should be apportioned between the user whose instructions prompted an output and the developers of the system and dataset. It posed this as a question, not a conclusion. No allocation should be assumed to be established.

The practical response is internal. Document who in the enterprise is accountable when agent-introduced code carries a licence obligation, obtain the vendor's and model providers' terms and have qualified counsel review what they limit or exclude. This guide is not legal advice.

Why review after the fact leaves a gap

Most licence assurance today happens late. Pull request review depends on a developer recognising a licence problem in a diff, and agents can produce large changes that include new dependencies. Periodic software composition analysis scans run on a schedule, so code can be deployed before the next scan identifies it.

NIST SP 800-218A states that its practices do not distinguish between human-written and AI-generated source code, because all source code is assumed to need evaluation before use. Agent output is therefore not exempt from pre-use checks. The cited text refers to vulnerabilities and other issues and does not name licence compliance, so each organisation should decide explicitly that licence checks sit within that evaluation.

The second gap is evidence. If AGPL code is found months later, legal, security and engineering teams need to know what the agent introduced, where it came from and what policy applied at the time. A pull request comment or a scan report from a later date does not answer those questions.

How Trussed enforces policy in the coding assistant's path

Trussed is runtime control, provenance and evidence infrastructure. It enforces policy in the execution path of coding assistants, alongside models, agents, tools and MCP servers. For individual interactions and tool calls, policy can allow, redact, block, rate limit or escalate for human approval. This is enforced at runtime, not reviewed after the fact.

Trussed code provenance records the origin, licence and security context of code. A regulated enterprise can use that context to write a licence policy, for example blocking a copyleft-licensed dependency or escalating an unclear case to a person, and to enforce it when the assistant acts.

Each enforcement decision produces audit-ready evidence, which supports the questions in the checklist above: what was introduced, where it came from and which policy applied. Evidence is mapped to frameworks including NIST, and deployment can be self-managed in the customer cloud with configurable retention and data residency. Trussed has run in continuous production in a regulated enterprise for more than 18 months. It is one way to close the gap, and the evaluation questions in this guide apply to any control you consider.